Skip to content

[bundleXpcf] Handle internal boost error 'boost::filesystem::copy_file: File exists' when using same location for input and output config file #36

@jillemash

Description

@jillemash

STEP TO REPRODUCE

  • use remaken bundleXpcf such as the file pointed by the xpcf_file argument (configuration file input) is located inside the destination directory.

This implies that the input file will likely be rewritten by bundleXpcf command when it will update the module paths.

EXPECTED BEHAVIOR
Not sure what the rule is supposed to be here, up to you.

It could either:

  • If authorized: silently, with a warning or with a confirmation prompt, overwrite the configuration file
  • Forbid this behavior completely and issue a clear error message

OBSERVED BEHAVIOR

  • Currently this is not possible and the following error message is issued:
[error]   boost::filesystem::copy_file: File exists [system:17]: "<abs path to the config file>, "<relative path to config file>"

The problem is that:

  • this looks like an internal message, and error could be handled at a higher level to give the user a friendlier message
  • as is, it's confusing because it seems to fail because the file exists. But if the given xpcf_file is not in the destination directory, but a file with the same name already exists in the destination directory, there is no error, and the file is silently overwritten. So this looks inconsistent.

So, bundleXPcf could either

  • handle the case where the input file is overwritten the same way as when we overwrite the already existing file in the dest dir
  • Forbid both cases (or warn) to be consistent (no overwrite, ensure output dir is clean)
  • Treat differently the case where we overwrite an input file compared to when we overwrite what might likely be already an output file, but in this case, maybe it just needs a clearer message (with no mention of boost), like for exemple "Error: Input XPCF config file will be overwritten by bundleXpcf".
  • Prevent from overwriting by default and use the --force option to bypass this constraint
  • ... ?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions