-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
Harmonize shutil.copymode() on Windows and POSIX #113188
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
Previously it worked differenly if dst is a symbolic link: it modified the permission bits of dst itself rather than the file it points to if follow_symlinks is true or src is not a symbolic link, and did nothing if follow_symlinks is false and src is a symbolic link. Also document similar changes in shutil.copystat() etc.
I am not sure whether this change should be backported. |
I left a comment on the PR pointing out the logic is too complicated for me to see exactly what changed. However, I'd suggest that as this function doesn't really do much of interest on Windows (read only property is the only mode we support, and it's not a security attribute), chances are the only people using it are using it for POSIX and just glad it works elsewhere. If they'll be glad that their non-readonly (rare) symlink to a (rare) readonly file now correctly copies the readonly attribute, then I'd say backport. (I maybe misunderstood the scenario, but I think the logic applies no matter, so probably backport after explaining the logic clearly in the docs.) |
Previously it worked differenly if dst is a symbolic link: it modified the permission bits of dst itself rather than the file it points to if follow_symlinks is true or src is not a symbolic link, and did nothing if follow_symlinks is false and src is a symbolic link.
Previously it worked differenly if dst is a symbolic link: it modified the permission bits of dst itself rather than the file it points to if follow_symlinks is true or src is not a symbolic link, and did nothing if follow_symlinks is false and src is a symbolic link.
#113285 is a solution for 3.12. |
Is there a specific reason we should fix |
My main motivation is to avoid adding complicated Backporting changes in |
Fair enough. Backporting the fix for the high level function seems okay to me now. |
…ows (GH-113285) Previously they worked differenly if dst is a symbolic link: they modified the permission bits of dst itself rather than the file it points to if follow_symlinks is true or src is not a symbolic link, and did nothing if follow_symlinks is false and src is a symbolic link.
…n Windows (pythonGH-113285) Previously they worked differenly if dst is a symbolic link: they modified the permission bits of dst itself rather than the file it points to if follow_symlinks is true or src is not a symbolic link, and did nothing if follow_symlinks is false and src is a symbolic link. (cherry picked from commit c7874bb) Co-authored-by: Serhiy Storchaka <[email protected]>
…ows (GH-113285) (GH-113426) Previously they worked differenly if dst is a symbolic link: they modified the permission bits of dst itself rather than the file it points to if follow_symlinks is true or src is not a symbolic link, and did nothing if follow_symlinks is false and src is a symbolic link. (cherry picked from commit c7874bb) Co-authored-by: Serhiy Storchaka <[email protected]>
Previously it worked differently if dst is a symbolic link: it modified the permission bits of dst itself rather than the file it points to if follow_symlinks is true or src is not a symbolic link, and did nothing if follow_symlinks is false and src is a symbolic link. Also document similar changes in shutil.copystat().
Previously it worked differently if dst is a symbolic link: it modified the permission bits of dst itself rather than the file it points to if follow_symlinks is true or src is not a symbolic link, and did nothing if follow_symlinks is false and src is a symbolic link. Also document similar changes in shutil.copystat().
Previously it worked differently if dst is a symbolic link: it modified the permission bits of dst itself rather than the file it points to if follow_symlinks is true or src is not a symbolic link, and did nothing if follow_symlinks is false and src is a symbolic link. Also document similar changes in shutil.copystat().
Previously it worked differently if dst is a symbolic link: it modified the permission bits of dst itself rather than the file it points to if follow_symlinks is true or src is not a symbolic link, and did nothing if follow_symlinks is false and src is a symbolic link. Also document similar changes in shutil.copystat().
Previously it worked differently if dst is a symbolic link: it modified the permission bits of dst itself rather than the file it points to if follow_symlinks is true or src is not a symbolic link, and did nothing if follow_symlinks is false and src is a symbolic link. Also document similar changes in shutil.copystat().
The behavior of
shutil.copymode()
on Windows was changed by addingos.lchmod()
in #59616. Now if follow_symlinks is false and both src and dst are symlinks, it copies the symlink mode (only the read-only bit). Previously it did nothing.But there is still a difference between Windows and POSIX. If follow_symlinks is true and dst is a symlink, it sets the permission of the symlink on Windows (because
os.chmod()
still does not follow symlinks by default on Windows) and the permission of the target on POSIX.shutil.copystat()
has different behavior, because it passes the follow_symlinks argument explicitly.I propose to harmonize
shutil.copymode()
behavior on Windows with POSIX and withshutil.copystat()
.Linked PRs
The text was updated successfully, but these errors were encountered: