Skip to content

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

Closed
sebastianpoeplau opened this issue Jul 3, 2024 · 5 comments
Closed
Assignees

Comments

@sebastianpoeplau
Copy link

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:

> mkdir test
> mkdir test/real
> cd test
> mklink /D link real
> dir
[...]
 Directory of C:\Users\itmgr\test

07/02/2024  04:07 PM    <DIR>          .
07/03/2024  08:42 AM    <DIR>          ..
07/02/2024  04:06 PM    <SYMLINKD>     link [real]
07/02/2024  04:06 PM    <DIR>          real
[...]

Note that the type of the link is SYMLINKD, indicating a directory link. (This corresponds to the flag SYMBOLIC_LINK_FLAG_DIRECTORY in the Windows API function CreateSymbolicLink.)

Now use sync_tree to copy the directory test somewhere else; the link type changes to SYMLINK:

[...]
 Directory of C:\Users\itmgr\synced

07/02/2024  04:07 PM    <DIR>          .
07/03/2024  08:42 AM    <DIR>          ..
07/02/2024  04:13 PM    <SYMLINK>      link [real]
07/02/2024  04:06 PM    <DIR>          real
[...]

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's fs::canonicalize or Python's os.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.)

@leocardao leocardao self-assigned this Jul 8, 2024
@leocardao
Copy link
Contributor

An MR is under review. I'll come back to you once it's merged. Thank you :)

@thvnx
Copy link

thvnx commented May 18, 2025

Hi, I'm guessing c021846 is a fix for this issue?

Just to let you know that the use of the strictargument in the call to realpath (in src/e3/fs.py) is only available after Python 3.10. The Python version on windows-latest CI machines in GitHub is 3.9.13, so master version of e3-core is no longer easily usable on Windows machines here.

@grouigrokon
Copy link
Contributor

I think this issue is fixec by 8a7832e and c25985f
As for the use of strict parameter, I will make a fix.
I will also add a test to make sure this current issue (#738) is fixed.

adacore-bot pushed a commit that referenced this issue May 19, 2025
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
adacore-bot pushed a commit that referenced this issue May 19, 2025
GitHub issue #738 is fixed,
a new test has been added to ensure it's now ok.

Ref #738
@grouigrokon
Copy link
Contributor

FYI, I will mark this issue as fixed. The test added by commit 0148b96 should prove it.

@thvnx , the use of parameter strict is now restricted to python version >= 10 See eda5c83. Thanks for pointing this out !

@thvnx
Copy link

thvnx commented May 19, 2025

Thanks for the quick fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants