Steve Dower <steve.do...@python.org> added the comment:
Thanks Eryk for your valuable response :) > readlink() and is_link() should be reserved for POSIX symlinks, i.e. only > IO_REPARSE_TAG_SYMLINK. I'm okay with that reasoning. 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). > they lack an associated filter driver that handles them in normal file > operations Also true, and likely to be a cause of more problems. But not ours to fix :) > How about adding a separate function such as nt.read_reparse_point() that's > able to read reparse points [...]? The internal implementation could be > shared with os.readlink. Maybe it can just return bytes and let the caller do the parsing? > The current behavior of follow_symlinks in stat() is problematic. It should > be limited to symlinks. 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? > The stat result would gain an st_reparse_tag field (already added by your > PR), which would be non-zero whenever a reparse point is opened. I agree this can stay. We don't need the rest of the logic here - callers who care to follow non-symlink reparse points can use the new nt.read_reparse_point() function to do it. ---------- _______________________________________ 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
