[issue40654] shutil.copyfile mutates symlink for absolute path

Eryk Sun added the comment: Modifying readlink() to return an str subclass that preserves the print name is an interesting idea, but not on topic here. For the cases where os.readlink is used to manually follow links (*), such as ntpath.realpath, using the substitute name is the most

[issue40654] shutil.copyfile mutates symlink for absolute path

Jason R. Coombs added the comment: What do you think about readlink returning something like: class Link(str): print_name = None # type: str | None @property def friendly_name(self) -> str: return self.print_name or self os.readlink would always return one of these Link objects,

[issue40654] shutil.copyfile mutates symlink for absolute path

Steve Dower added the comment: > how could one write the `cmd.exe` `dir` command using Python? I haven't checked, but if the dir command resolves the entire symlink chain rather than one step at a time, you'd use realpath (though that seems unlikely, tbh). Failing that, you'd add extra

[issue40654] shutil.copyfile mutates symlink for absolute path

Jason R. Coombs added the comment: Thanks Steve. While I was able to avoid the original symptom by not using readlink, I still think there's an issue here, both in the surprising behavior observed by shutil.copyfile, but also by the essential behavior of readlink. The more essential issue

[issue40654] shutil.copyfile mutates symlink for absolute path

Steve Dower added the comment: I think we can safely say this is by design (I know Jason got his backport working). > Understood. However, this statement assumes the "correct path" is the most > precise path to resolve the target. If you instead define "correct path" as > the one that

[issue40654] shutil.copyfile mutates symlink for absolute path

Jason R. Coombs added the comment: > Perhaps related... Now I'm thinking the issue is different, so I've created issue40732 to track the realpath issue. -- ___ Python tracker

[issue40654] shutil.copyfile mutates symlink for absolute path

Jason R. Coombs added the comment: > I'll see if `realpath` satisfies the test suite needs for path pie. I've tried replacing `readlink` with `realpath` and the tests still pass on Unix-like OSs, and also passes on Python 3.8 on Windows, but now fails on older Pythons on Windows. Is there

[issue40654] shutil.copyfile mutates symlink for absolute path

Jason R. Coombs added the comment: Perhaps related, I've encountered another apparent regression on Python 3.8 on Windows when the current working directory is in a symlink to another volume and one runs `setup.py develop` on a project using setuptools_scm

[issue40654] shutil.copyfile mutates symlink for absolute path

Jason R. Coombs added the comment: > Unless you're specifically testing single steps through symlink chains, you > probably want to just use realpath anyway. I do see now the references to `realpath` in the docs... and I think that satisfies the need I described above. It doesn't supply the

[issue40654] shutil.copyfile mutates symlink for absolute path

Jason R. Coombs added the comment: > Changing readlink to always return the correct path was deliberate. Understood. However, this statement assumes the "correct path" is the most precise path to resolve the target. If you instead define "correct path" as the one that would be most friendly

[issue40654] shutil.copyfile mutates symlink for absolute path

Steve Dower added the comment: > Presumably, I'll be able to add a pre-release of Python 3.9 to the pipelines > config at jaraco/skeleton - that will ensure that all projects I maintain > going forward will get tested on the pre-release. I don't have a straightforward task for it, but these

[issue40654] shutil.copyfile mutates symlink for absolute path

Steve Dower added the comment: Ah right, it's realpath() that has the final step to remove an unnecessary \\?\ prefix. Firstly, I still think fixing copy is more important and more valuable. Given the possibility that the print name won't point to the real target, I'd much prefer to keep

[issue40654] shutil.copyfile mutates symlink for absolute path

Jason R. Coombs added the comment: > This is only an issue for broken symlinks, right? (More precisely, those that > cannot be resolved, which may include very long paths on some machines.) Unfortunately, no. In the original post above, you can see temp/bar points to

[issue40654] shutil.copyfile mutates symlink for absolute path

Steve Dower added the comment: This is only an issue for broken symlinks, right? (More precisely, those that cannot be resolved, which may include very long paths on some machines.) Fixing copy is my preferred option. Also Jason, what do you need to be able to test against prerelease? It

[issue40654] shutil.copyfile mutates symlink for absolute path

Jason R. Coombs added the comment: I strongly suspect bpo-37834 and GH-15231 is where the difference was introduced. -- ___ Python tracker ___

[issue40654] shutil.copyfile mutates symlink for absolute path

Jason R. Coombs added the comment: Thank you Eryk for the thorough and informative investigation. Seriously, wow. > Do you want 3.8 to revert to using the print name, at least for symlinks? > (ntpath._readlink_deep would need to be modified to support long target > paths.) Or would you

[issue40654] shutil.copyfile mutates symlink for absolute path

Eryk Sun added the comment: Copying a symlink verbatim requires copying both the print name and the substitute name in the reparse buffer [1]. For a file, CopyFileExW: COPY_FILE_COPY_SYMLINK implements this by enabling the symlink privilege for the thread and copying the reparse point via

[issue40654] shutil.copyfile mutates symlink for absolute path

New submission from Jason R. Coombs : In https://github.com/jaraco/path/issues/186, the Path project discovered a regression with Python 3.8. It seems that if one creates a symlink with an absolute path. I used `shutil.copytree('temp', 'temp2', True)` and it produced this result: ``` ~ #