Message349504
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. |
|
Date |
User |
Action |
Args |
2019-08-12 22:57:36 | steve.dower | set | recipients:
+ steve.dower, paul.moore, tim.golden, zach.ware, eryksun |
2019-08-12 22:57:36 | steve.dower | set | messageid: <1565650656.96.0.475613012369.issue37834@roundup.psfhosted.org> |
2019-08-12 22:57:36 | steve.dower | link | issue37834 messages |
2019-08-12 22:57:36 | steve.dower | create | |
|