-
Notifications
You must be signed in to change notification settings - Fork 36
sync_tree turns Windows directory symlinks into file symlinks #738
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
An MR is under review. I'll come back to you once it's merged. Thank you :) |
Hi, I'm guessing c021846 is a fix for this issue? Just to let you know that the use of the |
In commit c021846, the call to `os.path.realpath` uses the `strict` parameter. Unfortunately, this parameter does not exist for python versions prior to 3.10. The default python version on GitHub CIs being 3.9, this parameter is problematic. This parameter is not used anymore for python versions prior to 3.10. Ref #738
Thanks for the quick fix! |
When
sync_tree
is used to copy a directory containing Windows directory symlinks, the resulting copy unexpectedly contains file symlinks instead.To reproduce the problem, set up a test directory in a Windows shell:
Note that the type of the link is
SYMLINKD
, indicating a directory link. (This corresponds to the flagSYMBOLIC_LINK_FLAG_DIRECTORY
in the Windows API functionCreateSymbolicLink
.)Now use
sync_tree
to copy the directorytest
somewhere else; the link type changes toSYMLINK
:The changed symlink causes the Windows function
GetFinalPathNameByHandle
to raise API error 123: "The filename, directory name, or volume label syntax is incorrect." The consequence is that the symlink breaks tools using Rust'sfs::canonicalize
or Python'sos.path.realpath(..., strict=True)
. (The non-strict version of the Python function catches OS error 123 and uses a workaround to still read the link.)The text was updated successfully, but these errors were encountered: