[issue44579] shutil.copy() inefficient implementation in Windows
New submission from sfmc : In Windows shutil.copy() uses _copyfileobj_readinto which copies file in user mode. In Windows there is an fast API to copy file in kernel mode: CopyFile (see https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-copyfile). -- components: Library (Lib) messages: 397076 nosy: sfmc priority: normal severity: normal status: open title: shutil.copy() inefficient implementation in Windows type: performance versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue44579> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43968] os.path.realpath() unexpected breaking change: resolves subst'd paths to real paths
sfmc added the comment: > How about keeping a substitute or mapped drive from the input path > if resolving the root path on the drive prefixes the overall real > path? That would be pretty easy to implement. So if the resolved path is accessible from the original path's drive, then keep the drive? This is what 'realpath' in Ruby does. Good idea, in my opinion. Letting this be default behavior (controlled by keyword argument) would prevent the issues with mounted drives. > For your own needs, you could add a sitecustomize.py file that > does "ntpath.realpath = ntpath.abspath". That will change the > behaviour back to what it was in 3.7. It works. Thank you very much. - Since you provided the working solution for me, the destiny of this bug report is at your discretion. -- ___ Python tracker <https://bugs.python.org/issue43968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43968] os.path.realpath() unexpected breaking change: resolves subst'd paths to real paths
sfmc added the comment: > If you don't need to resolve symlinks, just use os.path.abspath() in Windows > and os.path.realpath() in POSIX. As I said, we already fixed it in our scripts. The problem is with Python debugger and third-party tools - we can't make changes there. The environment variable would be easy fix to this issue. No impact on those who do not set the variable. - In our organization we use substituted drives for development, and no other tools (including other programming languages and their IDEs), except for Python 3.8+, had any problems with this. For example, in last versions of Perl and Ruby the realpath keeps the substitute drive. (In Ruby the realpath is also smart enough to resolve symlinks while keeping the drive.) - I consider this a serious issue with Python, I hope it gets the deserved attention and at least the workaround with env. var. gets implemented. -- ___ Python tracker <https://bugs.python.org/issue43968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43968] os.path.realpath() unexpected breaking change: resolves subst'd paths to real paths
sfmc added the comment: I see the point: the real path may not be accessible from the substitute drive: - if symlink (or junction) is used, pointing to path not visible from the substitute drive. - if different security context is used (e.g. different user or UAC). But that is the discussion about the _correct_ behavior (which may have differing opinions if the exact behavior is not documented). - Let's discuss how we can fix the issue caused by the behavior change. I propose a simple fix: keep old behavior if a special environment variable is specified. E.g. if you specify env. var. PYTHON_NTREALPATH_OLD_BEHAVIOR=1, it doesn't resolve symlinks and junctions. Is this acceptable for Python 3.8.10? -- ___ Python tracker <https://bugs.python.org/issue43968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43968] os.path.realpath() unexpected breaking change: resolves subst'd paths to real paths
New submission from sfmc :
For example if I mount directory
C:\example\dir
to
Z:\
the
os.path.realpath('Z:\\')
returns the real directory.
Use following commands in Windows to reproduce the issue:
md C:\example\dir
subst Z: C:\example\dir
python.exe -c "import os; print(os.path.realpath('Z:\\'))"
Python 3.8 outputs:
C:\example\dir
Python 3.7 outputs:
Z:\
This is unexpected behavior change and it breaks our scripts in many places,
because we use mounts in Windows ("subst" command) and Linux ("mount" command).
We had to add our own implementation for realpath to our scripts, but it also
affects other tools, such as Python debugger (breakpoints stopped working) and
IDEs (such as PyCharm).
It can be argued whether the behavior to resolve mounts is good.
But this change breaks the ability to work with Python scripts in mounts.
I hope it can be fixed in Python 3.8.10.
I propose to fix it in Python 3.8.10 by adding to function
os.path.realpath(path)
a new parameter (named for example "resolve_mounts"), like that:
os.path.realpath(path, *, resolve_mounts=False)
And if resolve_mounts==False, then the function should not resolve mounts in
Windows ("subst" command) and Linux ("mount" command).
Let me know if you wish to get a Pull Request with the proposed fix. I can try
to implement it.
--
components: Library (Lib)
messages: 392234
nosy: sfmc
priority: normal
severity: normal
status: open
title: os.path.realpath() unexpected breaking change: resolves subst'd paths to
real paths
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue43968>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
