Steve Dower <[email protected]> added the comment:
> I looked into this spawn problem. It's due to Cygwin's spawnve, which calls
> NtOpenFile to open the file, and then memory-maps it and reads the image
> header [1].
Great, that's roughly what I suspected. Unfortunately, I've been told that
looking into Cygwin's (GPL'd) code myself is going to cost me two weeks of dev
work ("cooling off" period), so someone else will have to help them fix it.
> It could parse out as much as possible and return a struct sequence
TBH, I feel like that's more work than is worth us doing for something that
will be relatively rarely used, will live in the stdlib, and is obviously
something that will become outdated as Microsoft adds new reparse points.
If we return the parsed data as opaque bytes then someone can write a simple
PyPI package to extract the contents. (Presumably the reparse tag will have
come from stat() already.)
> Maybe have two non-overlapping options, follow_symlinks and follow_nonlinks
I read this suggestion the first time and I think it would send the message
that we are more capable than we really are :)
In theory, we can't follow any reparse point that isn't documented as being
followable and provides the target name is a stable, documented manner. The
appexec links don't do this (I just looked at the returned buffer), so we
really should just not follow them. They exist solely so that CreateProcess
internally returns a unique error code that can be handled without impacting
regular process start, which means we *don't* want to follow them.
Again, if someone writes the PyPI package to parse all known reparse points,
they can do that.
Now, directory junctions are far more interesting. My gut feel is that we
should treat them the same as symlinks (with respect to stat vs. lstat) for
consistency, but I'll gladly defer to you (Eryk) for the edge cases that may
introduce.
---
My plan for PR 15231 is:
* make os.stat only follow symlinks and junctions
* make os.readlink only read symlinks and junctions
* add st_reparse_tag field to os.stat
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue37834>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
