Eryk Sun added the comment:
> I’m not suggesting that from within Python there should be another way
> to detect a home directory. The expanduser functionality as written is
> just fine for that, though I agree with Steve that using an API on
> Windows would be even better.
Eryk Sun added the comment:
There's no reason this can't be generalized to file attributes/flags on other
platforms such as st_flags on BSD/macOS and st_attributes on Linux (depending
on bpo-39533 -- but statx only returns a small subset of attributes that are
available via
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
Eryk Sun added the comment:
> these may overtake people's existing installs and replace them
> with something more clever (this annoys people)
In particular, installing the launchers to %SystemRoot% means that in some
contexts, such as the search path that CreateProcessW and Sear
Eryk Sun added the comment:
> For "python.exe", run as "py.exe", which is subject to shebangs,
> VIRTUAL_ENV, and PY_PYTHON.
Maybe in the "python[w].exe" case, it should skip shebang processing. That way
only py[w].exe would handle shebangs, such as
Eryk Sun added the comment:
> os.access() is not a good and sufficient permission check. It
> only checks DAC (discrete access control) permissions
That's interesting. In Linux, for example, I would expect the access() and
faccessat() system calls to also check mandatory per
Eryk Sun added the comment:
The __eq__ method would have to do a full resolve(), which is expensive and may
fail. One can't simply resolve "/foo/symlink/.." as "/foo", where "symlink" is
a filesystem symlink. The target has to be resolved before &quo
Change by Eryk Sun :
--
resolution: -> rejected
type: behavior -> enhancement
___
Python tracker
<https://bugs.python.org/issue42493>
___
___
Python-bugs-
Eryk Sun added the comment:
Python uses the Windows C runtime to parse the command line into an argument
array. By the CRT rules [1], you need to escape the embedded double quotes
using backslashes. For example:
PS C:\> python -c 's = \"fn main() {\"; s += \"\n\&q
Change by Eryk Sun :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Add to pathlib function to check permission similar to os.access
___
Python tracker
<https://bugs.python
Eryk Sun added the comment:
> takes extended file attributes like immutable bit
Just to clarify, immutable isn't an extended attribute. It's one of the flag
values in a Linux inode, which is supported by some filesystems such as ext4.
It's in the API as STATX_ATTR_IMMUTA
Change by Eryk Sun :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue42518>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Eryk Sun :
--
components: -Windows
___
Python tracker
<https://bugs.python.org/issue42518>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eryk Sun added the comment:
> The code of posixmodule.c looks very different now.
The conversion code was moved to FILE_TIME_to_time_t_nsec() in
Python/fileutils.c.
time_t is a signed 64-bit integer type, so there's no immediate problem storing
1601-01-01 as the negative (pre-epo
Change by Eryk Sun :
--
versions: +Python 3.10
___
Python tracker
<https://bugs.python.org/issue32381>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eryk Sun :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Python 3.6 cannot reopen .pyc file with non-ASCII path
___
Python tracker
<https://bugs.python
Eryk Sun added the comment:
> To implement PEP 446: create non-inheritable file descriptors.
Side note. That aspect is still wonky in Windows, for which set_inheritable()
cannot be implemented reliably since there's no way to change whether an
existing CRT file descriptor is inh
Eryk Sun added the comment:
I suggesting changing the name to indicate that only OSError exceptions are
suppressed, not SubprocessError exceptions. Maybe call it no_oserror.
As to the status code to use, if you want a a common code that can't interfere,
it has to be either a negative
Eryk Sun added the comment:
> ImportError: DLL load failed while importing _jpype:
> A dynamic link library (DLL) initialization routine failed.
With loader snaps enabled for python[_d].exe (i.e. loader debug messages), you
can attach a debugger to discover which DLL's init
Eryk Sun added the comment:
I built JPype normally in release mode and was able to analyze the problem
using the platform debugger (cdb or WinDbg). I think the issue is pretty
straight forward. The static initializer for classMagic in
"native\python\pyjp_class.cpp" is calling
Eryk Sun added the comment:
> I understand Python should be using reading the current CP (from
> GetConsoleOutputCP
> or using the default OEM CP, and not assuming ANSI CP for stdio
A while ago I analyzed text encodings used by many of the legacy CLI programs
in Windows. Some prog
Eryk Sun added the comment:
> How about treating only UTF-8 and leave legacy environment as-is?
> * When GetConsoleCP() returns CP_UTF8, use UTF-8 for stdin.
> Otherwise, use ANSI.
Okay, and also when GetConsoleCP() fails because there's no console (e.g.
python.exe w/ DE
Eryk Sun added the comment:
> When there is no console, stdio should use the default textio
> encoding that is ANSI for now.
stdin, stdout, and stderr are special and can be special cased because they're
used implicitly for IPC. They've always been acknowledged as special b
Eryk Sun added the comment:
When a process executes in the background from a non-interactive bash script,
the initial handler for SIGINT is SIG_IGN (ignore). Prior to 3.7,
_thread.interrupt_main() tries to trip SIGINT even when the C handler is set to
SIG_IGN. But Python uses an integer
Eryk Sun added the comment:
> Python 3.7 added the support for the PROC_THREAD_ATTRIBUTE_HANDLE_LIST
> in subprocess.STARTUPINFO: lpAttributeList['handle_list'] parameter.
The motivating reason to add support for the WinAPI handle list was to allow
changing the default t
Eryk Sun added the comment:
> As the legacy cmd.exe can be easily replaced, that leaves python.exe.
python.exe is a console application, which attaches to a console session. Since
Windows 7, each console session is hosted by an instance of conhost.exe.
The CMD shell (cmd.exe) is a cons
Eryk Sun added the comment:
> "lowercase two strings by means of LCMapStringEx() and then wcscmp
> the two" always gives the same result as "compare the two strings
> with CompareStringOrdinal()"
For checking case-insensitive equality, it shouldn't matt
Eryk Sun added the comment:
> Windows doesn't let you remove files and directories that are used
> by a process.
Windows does allow deleting open files/directories, but read/execute,
write/append, and delete/rename access have to be explicitly shared when
opening a file o
Eryk Sun added the comment:
> def test_chdir():
> with tempfile.TemporaryDirectory() as tempdir:
> old = os.getcwd()
> os.chdir(tempdir)
> with open(os.path.join(tempdir, "delme")) as fout:
> fout.write("Hello")
&g
Eryk Sun added the comment:
> For Windows though, I'm unsure.
If copystat() gains the ability to copy the file's owner and group in POSIX, it
is not a priority to mirror this capability in Windows, which doesn't implement
anything like the Unix owner-group-other permissi
Eryk Sun added the comment:
> "http:" isn't a valid drive letter, I'd imagine.
It's not a valid DOS drive, but that's not the problem. "http://w.org"; is
parsed as a relative path. The double slashes are replaced by a single
backslash, and the Win
Eryk Sun added the comment:
An alternative would be to add a "strict" parameter that defaults to False. In
non-strict mode, map all OSError exceptions to a False return value. In strict
mode, use _ignore_error(e) to determine whether to return False or propagate
the exception. Th
Eryk Sun added the comment:
NT filesystems are specified to fail with STATUS_OBJECT_PATH_NOT_FOUND
(0xC03A) if a parent component in a path either does not exist or is not a
directory. In the Windows API, this translates to ERROR_PATH_NOT_FOUND (3),
which in the C runtime translates to
Eryk Sun added the comment:
> assert '''"""''' == '""""' # Fails
The left-hand side is a triple-quote string literal [1][2] that contains 3
double-quote characters. The right-hand side is a single-quote string
Eryk Sun added the comment:
> I still don't understand if the issue involves Py_SetPath() or not.
It seems to me that this issue is concerned with the default behavior that
looks for the "lib/os.py" landmark via search_for_prefix() in PC/getpathp.c.
Starting at the image
Eryk Sun added the comment:
shutil.move() has always fallen back on copy/unlink if os.rename() fails. This
used to be clearly documented to account for the behavior of os.rename() in
Windows, but the details were obscured over multiple rewrites. Currently the
documentation makes it seem
Change by Eryk Sun :
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.10
___
Python tracker
<https://bugs.python.org/issue42
Eryk Sun added the comment:
I can help, but in this case there isn't much to do. Just replace os.rename()
with os.replace(), make a minor doc change, and maybe add a test that ensures a
junction can be moved over an existing file on the same filesystem. For example:
>>>
Eryk Sun added the comment:
Symlinks and mountpoints (aka junctions) contain two forms of the target path.
There's a path that's intended for display in the shell, and there's the actual
substitute path to which the link resolves. os.readlink() was changed to return
the
Eryk Sun added the comment:
FYI, Windows is not a POSIX operating system and does not implement Unix
signals in the kernel. That said, the C language serves as a base level of
cross-platform support for language runtimes across most operating systems, and
there's significant cou
Eryk Sun added the comment:
> 4. In console A, type the PID from console B and execute the command.
In Windows, os.kill() is a rather confused function. In particular, it confuses
a process ID (pid) with a process group ID (pgid). If the signal is
CTRL_C_EVENT or CTRL_BREAK_EVENT, it fi
Eryk Sun added the comment:
> I just reported it because the SystemError indicates that a C-API function
> was returning non-NULL even after PyErr_Occurred() returns true
Fixing the SystemError should be simple. Just clear an existing error if
TerminateProcess() succeeds.
> Window
Eryk Sun added the comment:
> Should there be a `return NULL;` between these two lines?
In 3.x, os.kill() has always fallen back on TerminateProcess() when
GenerateConsoleCtrlEvent() fails, and I assumed that was intentional. But I
misunderstood that it's not actually chaining the e
Eryk Sun added the comment:
> That's what Lib/test/win_console_handler.py:39 does.
No, that script is currently broken.
SetConsoleCtrlHandler(None, False) clears the Ctrl+C ignore flag in the PEB
ProcessParameters, which is normally inherited by child processes. But us
Eryk Sun added the comment:
os.readlink() was generalized to support mountpoints (junctions) as well as
symlinks, and it's more common for mountpoints to lack the print name field in
the reparse data buffer [1]. For example, PowerShell's new-item creates
junctions that o
Eryk Sun added the comment:
> os.write(fd) can't ... know that the fd was opened with O_APPEND
It's possible to query the granted access of a kernel handle via NtQueryObject:
ObjectBasicInformation -- not that I'm suggesting to use it.
> the most serious one is rat
Eryk Sun added the comment:
I'm not fond of the way reduction.DupHandle() expects the receiving process to
steal the duplicated handle. I'd prefer using the resource_sharer module, like
reduction.DupFd() does in POSIX. Except spawning is a special case, for which
reduction.DupHa
Eryk Sun added the comment:
> can a new handle have non-default access rights? Or can the
> default change at this point of Windows history?
I don't know what you mean by default access rights.
C open() requests generic access rights, which map to the standard and
file-specifi
Eryk Sun added the comment:
FYI, here are the access rights applicable to files, including their membership
in generic (R)ead, (W)rite, and e(X)execute access:
0x0100_ --- ACCESS_SYSTEM_SECURITY
0x0010_ RWX SYNCHRONIZE
0x0008_ --- WRITE_OWNER
0x0004_
Eryk Sun added the comment:
> I've found a catch via ProcessHacker: CreateFile() with
> GENERIC_WRITE (or FILE_GENERIC_WRITE) additionally grants
> FILE_READ_ATTRIBUTES for some reason.
CreateFileW always requests at least SYNCHRONIZE and FILE_READ_ATTRIBUTES
access.
T
Eryk Sun added the comment:
Thanks, Terry. I should have followed up with a short message asking for a core
developer to sign off on that suggestion, in which case this is an "easy (C)"
issue.
--
___
Python tracker
<https://bu
Eryk Sun added the comment:
"python3.dll" doesn't directly depend on "python39.dll", so the loader waits to
load it until first accessed via GetProcAddress(). It should remember the
activation context of "python3.dll", such as whether it was load
Eryk Sun added the comment:
> So I need to dynamically load *both* python3.dll and python39.dll,
> but if I do that I can get the functions from python3.dll?
No, just load the fully-qualified name of "python3.dll", with the loader flags
LOAD_LIBRARY_SEA
Eryk Sun added the comment:
> h = LoadLibraryW(L"some/path/to/python3.dll")
You should be using LoadLibraryExW(). It's a one-time call. You do not need to
set the default flags via SetDefaultDllDirectories().
--
___
Pyth
Eryk Sun added the comment:
I noted that the path to "python3.dll" must be fully qualified. But let me
stress that point. You cannot use the relative path "path/to/python3.dll" with
LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR. The loader will fail the call as an invalid
paramet
Eryk Sun added the comment:
> uses a code snippet like this.
PathAllocCombine() is Windows 8+, so sample code that uses it would only be for
Python 3.9+.
I'd prefer the function pointer to be returned as an out parameter, and return
an HRESULT status as the result. If LoadLibrary
Eryk Sun added the comment:
> So the idea is to delete the file for a brief period, but then
> undelete it.
Currently NTFS defaults to using classic delete semantics for delete-on-close.
However, it supports POSIX delete semantics for delete-on-close, so the default
could chang
Eryk Sun added the comment:
bpo-39533 is a related issue that seeks to support the Linux statx() system
call. A statx record includes an stx_attributes field, which supports the
following file attributes that can be set with chattr:
[a]ppend: STATX_ATTR_APPEND
[c]ompressed
Eryk Sun added the comment:
I assume you're linking to the CRT dynamically, which is shared with
"python39.dll", which means you're sharing the configured locale with Python.
Since you're not using an isolated configuration, the LC_CTYPE locale will be
set to t
Eryk Sun added the comment:
When an open attempts to access a directory as data, the error code from WinAPI
CreateFileW is ERROR_ACCESS_DENIED (5), which maps to C EACCES and thus raises
Python PermissionError.
Python's io.FileIO() type could handle an EACCES error in Windows by che
Eryk Sun added the comment:
I'd prefer to leave ".." in the path, at least with PosixPath. (It doesn't
matter with WindowsPath.) The "there" component may be a symlink that's
currently inaccessible. That said, Python's os.path.realpath()
Eryk Sun added the comment:
On most platforms, unless UTF-8 mode is enabled,
locale.getpreferredencoding(False) returns the LC_CTYPE encoding of the current
locale. For example, in Linux:
>>> locale.setlocale(locale.LC_CTYPE, 'en_US.UTF-8'
Change by Eryk Sun :
--
components: +IO, Library (Lib)
title: build-in open() doesn't use whatever locale.getpreferredencoding()
returns as default encoding. -> built-in open() doesn't use
locale.getpreferredencoding() as the default encoding
versions:
Eryk Sun added the comment:
The SIZE [1] type for a rectangle has nothing to do with SIZE_T [2], the
integer type that's returned by C sizeof(). SIZE_T isn't defined in wintypes. A
new issue can be opened to add more of the common data types to wintypes.
Here's an examp
Eryk Sun added the comment:
> What's the correct way to set the DLL search path when running a python
> script?
If possible, the simplest approach is to put dependent DLLs in the same
directory as the extension module.
In 3.8+, the search path for the dependent DLLs of a normal
Eryk Sun added the comment:
The conflict between 32-bit and 64-bit user site-packages was resolved in issue
41627, starting with Python 3.10. It's not practical to backport this change to
existing 3.9 installations.
The "nt_user" install scheme was changed to use the
Eryk Sun added the comment:
> If my understanding is right, the open() will invoke
> locale.getpreferredencoding() by setting the do_setlocale=False
> -- i.e. locale.getpreferredencoding(False) -- to avoid invoking
> setlocale(LC_CTYPE, "").
Yes, that's the
Eryk Sun added the comment:
NoneType would have to be replaced with None in make_funcptrtype_dict() and
PyCFuncPtr_set_restype() in Modules/_ctypes/_ctypes.c. In the C API, NoneType
is (PyObject *)&_PyNone_Type.
--
nosy: +eryksun
___
Py
Eryk Sun added the comment:
> and it happens that "pkg" is found in a folder that is
> given in sys.path as a relative path
I'd prefer that Python disallowed relative paths in sys.path [1]. But since
they're allowed, I think importlib at least could try to resolve
Change by Eryk Sun :
--
versions: +Python 3.7
___
Python tracker
<https://bugs.python.org/issue43105>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eryk Sun added the comment:
> IsADirectoryError: [Errno 21] Is a directory: 'not_a_dir/'
The trailing slash forces the OS to handle "not_a_dir" as a directory [1].
A pathname that contains at least one non- character and that
ends with one or more trailing
Eryk Sun added the comment:
Python uses standard Unicode character properties, as defined by the Unicode
Consortium. This issue is discussed in their FAQ [1]:
Q: Why does ß (U+00DF LATIN SMALL LETTER SHARP S) not uppercase to
U+1E9E LATIN CAPITAL LETTER SHARP S by default?
A
Eryk Sun added the comment:
winreg.DeleteKey[Ex] does not require any particular access on the `key`
handle. This handle is used only as the native NT API RootDirectory [1] when
opening `subkey` with DELETE access via NtOpenKeyEx [2].
The extra access with winreg.DeleteKeyEx [3] is just to
Eryk Sun added the comment:
The IDLE shortcut that's installed by the development distribution runs
`"\pythonw.exe" "\Lib\idlelib\idle.pyw"`.
Thus opening a file that's pinned to the jumplist will execute it as a script
via "pythonw.exe".
To integ
Eryk Sun added the comment:
The two files in "files.zip" have the same contents:
>>> open('source.css', 'rb').read() == open('destination.css', 'rb').read()
True
Maybe there's something peculiar about the stat results.
Eryk Sun added the comment:
Issue 41976 added ctypes.util._is_elf() to filter out linker scripts such as
"libc.so". The PR was backported to 3.7. _is_elf() assumes the trace result has
absolute paths that can be opened, but Matthias is getting the relative
filename "liblibc.a
Eryk Sun added the comment:
Can't there be a library named "libc" with the shared module "liblibc.so"? It
seems to me that the _is_elf() function added in issue 41976 is breaking the
contract that "[i]f no library can be found, returns None". It's no
Eryk Sun added the comment:
I left this open in case someone wants to modify shutil.copy() and
shutil.copy2() to raise a less misleading exception when `dst` names a
non-existing directory such as 'not_a_dir/'. Failing with IsADirectoryError
(errno EISDIR) is confusing since s
Eryk Sun added the comment:
> What does use getlocale is time.strptime and datetime.datetime.strptime
calendar.LocaleTextCalendar also uses getlocale() and getdefaultlocale(). The
result from getdefaultlocale() cannot be set via setlocale() in Windows, which
also breaks resetloc
Eryk Sun added the comment:
> Is this the same as the other issue where get_locale is normalising
> the result according to some particular glibc logic and isn't at
> all portable?
If I understand Anders' immediate problem correctly, I think it can be
addressed by using
Eryk Sun added the comment:
> The APIs were written at a time where locale modifiers
> simply did mot exist.
Technically, locale modifiers did exist circa 2000, but I suppose you mean that
they were uncommon to the point of being unheard of at the time.
The modifier field was specif
Eryk Sun added the comment:
> but at least for clean installs of 3.10 we can avoid the need
> for admin completely
Except updating PATHEXT always requires admin access. I do this manually by
setting a user PATHEXT variable with %PATHEXT% as the first item and append the
extensions
Eryk Sun added the comment:
The sys.stdout TextIOWrapper is stuck in a bad state. When the write() method
is called with an ASCII string, it implements an optimization that stores a
reference to the str() object in the internal pending_bytes instead of
immediately encoding the string
Eryk Sun added the comment:
Issue 36748 added the ASCII optimization in write(), so I'm adding Inada Naoki
to the nosy list.
--
nosy: +methane
___
Python tracker
<https://bugs.python.org/is
Eryk Sun added the comment:
> stdout.write("small text")
> stdout.write("very large text") # Calls writeflush, but can not allocate
> buffer.
Without the optimization, in most cases this will likely fail in
_io_TextIOWrapper_write_impl() at the line `b =
Eryk Sun added the comment:
> In your code, huge data passed to .write(huge) may be
> remained in the internal buffer.
If you mean the buffered writer, then I don't see the problem. A large bytes
object in pending_bytes gets temporarily referenced by
_textiowrapper_writeflush(
Eryk Sun added the comment:
> Isn't `PyUnicode_GET_LENGTH(text) < self->chunk_size` enough?
Yes, that's simpler, except with `<=`" instead of `<`, since the maximum count
is chunk_size when pending_bytes is a list or ASCII string. When I wrote the
more co
Eryk Sun added the comment:
Here's an implementation of attributes_from_dir() that strips trailing slashes
(e.g. "C:/spam///" -> "C:/spam"), which entails copying the const string up to
the last character that's not a slash. Rooted paths and drive paths that
Eryk Sun added the comment:
On second thought, I think it's cleaner and avoids potential race conditions to
implement ntpath.sameopenfile(). Then use that to implement ntpath.samefile().
Here's a summary of suggested changes, with sample code to flesh out the
concepts:
*
Change by Eryk Sun :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
title: shutil. copy file throws incorrect SameFileError on Google Drive File
Stream -> spam
___
Python tracker
<https://bugs.python
Change by Eryk Sun :
--
Removed message: https://bugs.python.org/msg387521
___
Python tracker
<https://bugs.python.org/issue43298>
___
___
Python-bugs-list mailin
Change by Eryk Sun :
--
Removed message: https://bugs.python.org/msg387525
___
Python tracker
<https://bugs.python.org/issue43298>
___
___
Python-bugs-list mailin
Change by Eryk Sun :
--
Removed message: https://bugs.python.org/msg387522
___
Python tracker
<https://bugs.python.org/issue43298>
___
___
Python-bugs-list mailin
Eryk Sun added the comment:
ntpath.realpath() has since been implemented, and it addresses the problem by
keeping the extended (verbatim) path prefix in the result if the input argument
has it, and otherwise removing the prefix if the final path resolves correctly
without it
Change by Eryk Sun :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue22961>
___
Change by Eryk Sun :
--
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue22976>
___
___
Change by Eryk Sun :
--
components: +IO
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.4, Python
3.5
___
Python tracker
<https://bugs.python.org/issue22
Change by Eryk Sun :
--
Removed message: https://bugs.python.org/msg345454
___
Python tracker
<https://bugs.python.org/issue37198>
___
___
Python-bugs-list mailin
Eryk Sun added the comment:
> All getlocale is used for in _strptime.py is comparing the value
> returned to the previous value returned.
Which is why _strptime should be calling setlocale(LC_TIME), the same as the
calendar module. That's not to say that I don't think
Change by Eryk Sun :
--
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue23634>
___
___
801 - 900 of 2119 matches
Mail list logo
