[issue22107] tempfile module misinterprets access denied error on Windows
Erik Aronesty added the comment: i would like to point out that the primary reason any of this nonsense exists is because of short filename restrictions. i've replaces nearly all of my temp file creation code in all of my project to `return os.urandom(32).hex()` ... which is reliable secure, fast, and doesn't require any fileops sure, it doesn't work on 8.3 limited systems, but maybe the NamedTemp code should check that *first* and *if* it's OK to use long names... just use them, otherwise revert to existing behavior -- ___ Python tracker <https://bugs.python.org/issue22107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31842] pathlib: "Incorrect function" during resolve()
Erik Aronesty added the comment:
bug is worse than that:
perfectly valid redirected paths (winfsp ram drives for example) now break in
python 3.9.6 (maybe fixed in later version?)
>>> import pathlib
>>> p=pathlib.Path('C:\\Users\\erik\\Atakama')
>>> p.resolve()
Traceback (most recent call last):
File "", line 1, in
File "c:\users\erik\.pyenv\pyenv-win\versions\3.9.6\Lib\pathlib.py", line
1205, in resolve
s = self._flavour.resolve(self, strict=strict)
File "c:\users\erik\.pyenv\pyenv-win\versions\3.9.6\Lib\pathlib.py", line
206, in resolve
s = self._ext_to_normal(_getfinalpathname(s))
OSError: [WinError 1005] The volume does not contain a recognized file system.
... yet
dir 'C:\\Users\\erik\\Atakama'
Desktop.ini Personal\ Files Vault
mounted via winfsp
--
nosy: +earonesty
versions: +Python 3.9 -Python 3.8
___
Python tracker
<https://bugs.python.org/issue31842>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22107] tempfile module misinterprets access denied error on Windows
Erik Aronesty added the comment: This is the fist of what I'm using: https://gist.github.com/earonesty/a052ce176e99d5a659472d0dab6ea361 Seems OK for my use cases. There's probably issues with relying on __del__ this way. But it solves the Windows close/reopen problem, too. -- ___ Python tracker <https://bugs.python.org/issue22107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35003] Provide an option to venv to put files in a bin/ directory on Windows
Erik Aronesty added the comment: the single Scripts/activate tool should be simply copied to bin/activate ... this is what you have to do to write a bash script for python now: source bin/activate || source Scripts/activate we should not assume that all windows users use things like CMD and PowerShell, and instead just make support for "shell activation" be cross-platform -- nosy: +earonesty ___ Python tracker <https://bugs.python.org/issue35003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35003] Provide an option to venv to put files in a bin/ directory on Windows
Change by Erik Aronesty : -- pull_requests: +17474 pull_request: https://github.com/python/cpython/pull/18083 ___ Python tracker <https://bugs.python.org/issue35003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35003] Provide an option to venv to put files in a bin/ directory on Windows
Erik Aronesty added the comment: See https://github.com/python/cpython/pull/18083 for an example of a 'simple copy' for shell script compatibility ... rather than trying to make Scripts move around (which it can't trivially). -- ___ Python tracker <https://bugs.python.org/issue35003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35003] Provide an option to venv to put files in a bin/ directory on Windows
Erik Aronesty added the comment: > The Scripts/bin thing is not specific to venv - for whatever reason, the > original Windows implementation chose to use "Scripts" rather than "bin" That's irrelevant to the PR, which solves the problem in a compatible way. There's no compatibility issues if a link is made to the activate script, rather than moving the directory at all. > My guess is you would need to propose a PEP to move *everything* over from > "Scripts" to "bin" in the Windows Python world Certainly not. That would break everything and would be a bad idea. > This issue was already rejected before you added your PR so I'm not sure why > you went to the trouble of creating a PR. Because the issue was rejected due to come conflating logic and confusion as to what the underlying problem and issue is. The venv system produces files specifically for activation on Windows which must and should reside in the Scripts directory. The venv system also produces files for activation in a bash (or similar) shell. This *should* reside in the bin directory (there is no o/s dependency here), and it should *also* reside in the Scripts directory ... for compatibility. Expressed that way, it's clear what the solution is. Hence the PR. -- ___ Python tracker <https://bugs.python.org/issue35003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37477] NamedTemporaryFile can hang on windows
New submission from Erik Aronesty : Depending on the user's permissions, this code can hang, instead of raising an exception: from tempfile import NamedTemporaryFile NamedTemporaryFile(dir="/") The problamatic code is in tempfile.py: When encountering a "[Errno 13] Permission denied: '/tmpmcupmo_g'", the current code uses _os.access(dir, _os.W_OK) in two places to check if access is allowed to write to the directory. On windows, _os.access does not check if the user has permission to write to the folder, it only checks if the folder is read-only (and it doesn't even do a good job at that). So the temp file creator loops for a rather long time, and consumes a massive amount of system resources, because os.TMP_MAX on modern windows versions is 2147483647. This article explains how to check if a directory can-write without trying to write to it: http://blog.aaronballman.com/2011/08/how-to-check-access-rights/ Alternatively, a more careful check of the winerror return value from the open call *might* be sufficient. -- messages: 347073 nosy: earonesty priority: normal severity: normal status: open title: NamedTemporaryFile can hang on windows versions: Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue37477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37477] NamedTemporaryFile can hang on windows
Change by Erik Aronesty : -- type: -> crash ___ Python tracker <https://bugs.python.org/issue37477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37477] NamedTemporaryFile can hang on windows
Erik Aronesty added the comment: yes, duplicate of https://bugs.python.org/issue22107 ... tried looking first, sry. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22107] tempfile module misinterprets access denied error on Windows
Erik Aronesty added the comment:
Series of operations needed to answer the questions os.access is not answering
on windows:
bool CanAccessFolder( LPCTSTR folderName, DWORD genericAccessRights )
{
bool bRet = false;
DWORD length = 0;
if (!::GetFileSecurity( folderName, OWNER_SECURITY_INFORMATION |
GROUP_SECURITY_INFORMATION
| DACL_SECURITY_INFORMATION, NULL, NULL, &length ) &&
ERROR_INSUFFICIENT_BUFFER == ::GetLastError()) {
PSECURITY_DESCRIPTOR security = static_cast< PSECURITY_DESCRIPTOR >(
::malloc( length ) );
if (security && ::GetFileSecurity( folderName,
OWNER_SECURITY_INFORMATION | GROUP_SECURITY_INFORMATION
| DACL_SECURITY_INFORMATION, security, length,
&length )) {
HANDLE hToken = NULL;
if (::OpenProcessToken( ::GetCurrentProcess(), TOKEN_IMPERSONATE |
TOKEN_QUERY |
TOKEN_DUPLICATE | STANDARD_RIGHTS_READ, &hToken )) {
HANDLE hImpersonatedToken = NULL;
if (::DuplicateToken( hToken, SecurityImpersonation,
&hImpersonatedToken )) {
GENERIC_MAPPING mapping = { 0x };
PRIVILEGE_SET privileges = { 0 };
DWORD grantedAccess = 0, privilegesLength = sizeof(
privileges );
BOOL result = FALSE;
mapping.GenericRead = FILE_GENERIC_READ;
mapping.GenericWrite = FILE_GENERIC_WRITE;
mapping.GenericExecute = FILE_GENERIC_EXECUTE;
mapping.GenericAll = FILE_ALL_ACCESS;
::MapGenericMask( &genericAccessRights, &mapping );
if (::AccessCheck( security, hImpersonatedToken,
genericAccessRights,
&mapping, &privileges, &privilegesLength,
&grantedAccess, &result )) {
bRet = (result == TRUE);
}
::CloseHandle( hImpersonatedToken );
}
::CloseHandle( hToken );
}
::free( security );
}
}
return bRet;
}
--
nosy: +earonesty
___
Python tracker
<https://bugs.python.org/issue22107>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31842] pathlib: "Incorrect function" during resolve()
Change by Erik Aronesty : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker <https://bugs.python.org/issue31842> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31842] pathlib: "Incorrect function" during resolve()
New submission from Erik Aronesty :
When strict is "false", pathlib should not fail if the network share is
inaccessible. It should, as documented, catch the exception and continue with
as much of the path as it has.
>>> pathlib.Path("v:").resolve()
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\erik\AppData\Local\Programs\Python\Python36\lib\pathlib.py",
line 1119, in resolve
s = self._flavour.resolve(self, strict=strict)
File "C:\Users\erik\AppData\Local\Programs\Python\Python36\lib\pathlib.py",
line 193, in resolve
s = self._ext_to_normal(_getfinalpathname(s))
OSError: [WinError 1] Incorrect function: 'v:'
--
messages: 304767
nosy: earonesty2
priority: normal
severity: normal
status: open
title: pathlib: "Incorrect function" during resolve()
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue31842>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31853] Use super().method instead of socket.method in SSLSocket
New submission from Erik Aronesty : I asked on #python-dev and was told that it's most likely due to legacy reasons that the class has things like `socket.__init__` instead of `super().__init__` -- assignee: christian.heimes components: SSL messages: 304838 nosy: christian.heimes, earonesty priority: normal pull_requests: 4063 severity: normal status: open title: Use super().method instead of socket.method in SSLSocket type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31853> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
