Raise when symlinks use different drive in Windows - #6201
Conversation
guban
left a comment
There was a problem hiding this comment.
To see whether swallowing the error is appropriate, consider two scenarios:
- Scenario A: The user intentionally wants to export a symlink.
- Scenario B: The user does not export the symlink.
Also, keep in mind that the symlink is not necessarily committed to the version control: it could be made just for a local use and added to .gitignore.
In scenario A, we should fail, telling the user that exporting the symlink is a bad idea and is not supported for the user's own good. Swallowing the error in this scenario is not good.
In scenario B, we can swallow the error because the symlink is not exported, so it won't cause any problems for conan export command. In this scenario, though, we shouldn't even touch that symlink: the processing should be applied only to the files that are actually exported.
Considering that
- both scenarios are unusual and rare, and
- implementing scenario B is probably quite expensive,
a good solution is to always fail with an error (i.e., treating all scenarios as scenario A), and print the symlink path as part of error message, so that users in scenario B could easily find the culprit.
+1 |
|
Understood, made it fails always with an informative message. |
jgsogo
left a comment
There was a problem hiding this comment.
Easy solution. Totally agree this is the best we can do 👍
Changelog: Fix: Raise error for symlinks in Windows that point to a different unit.
Docs: Omit
Close #6197
Note this is almost impossible to test: it requires Administrator permissions to create a unit X: and then mklink to it to reproduce