Eryk Sun <eryk...@gmail.com> added the comment:
> Honestly, the only real problem I've seen is in applications that use > a reimplementation of spawn() rather than the UCRT's version (which > handles the reparse point jsut fine). 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]. For an app-exec link, this fails with STATUS_IO_REPARSE_TAG_NOT_HANDLED, which is translated to Windows ERROR_CANT_ACCESS_FILE (1920). In turn, Cygwin translates this error to its to default errno value, EACCES. (The Windows CRT uses EINVAL as the default.) [1] https://github.com/cygwin/cygwin/blob/aa55d22cb55d67d7f77ee9d58f9016c42c3ee495/winsup/cygwin/spawn.cc#L1035 > Maybe it can just return bytes and let the caller do the parsing? It could parse out as much as possible and return a struct sequence: ReparseTag (int) ReparseGuid (string, or None for Microsoft tags) SymlinkFlags (int, SYMLINK_FLAG_RELATIVE) PrintName (string or None) SubstituteName (string or None) DataBuffer (bytes) Only the ReparseTag and DataBuffer fields would always be present. ReparseGuid would be present for non-Microsoft tags (i.e. bit 31 is unset). The result could maybe have one or more fields for the app-exec-link type. > This sounds like a good option to me, too. So that would suggest that > Modules/posixmodule.c in win32_xstat_impl would verify both > FILE_ATTRIBUTE_REPARSE_POINT and IO_REPARSE_TAG_SYMLINK? And if the > tag is different it'll return information about the reparse point > rather than the target? Maybe have two non-overlapping options, follow_symlinks and follow_nonlinks. The latter might be more sensible as a single option for lstat(), since it never follows symlinks. Then if either follow_symlinks or follow_nonlinks is false, stat has to open the reparse point and get the tag to determine whether it should reopen with reparsing enabled. The straight-forward way to get the tag is GetFileInformationByHandleEx: FileAttributeTagInfo. This should succeed if the file system supports reparse points. But still check for FILE_ATTRIBUTE_REPARSE_POINT in the attributes before trusting the tag value. If the call fails, assume it's not a reparse point and proceed to GetFileInformationByHandleW. Another tag to look for is IO_REPARSE_TAG_AF_UNIX (0x8000_0023). It's relatively new, so I haven't used it yet. I suppose it should be mapped S_IFSOCK in the stat result. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37834> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
