Steve Dower <> added the comment:

[Quoting from the PR comments]

> traverse is from follow_symlinks and only applies to symlinks. It does not 
> apply to other types of reparse points.

I get your argument that junctions are not symlinks, but I disagree that we 
should try this hard to emulate POSIX semantics rather than letting the OS do 
its thing. We aren't reparsing anything ourselves (in the PR) - if the OS is 
configured to do something different because of a reparse point, we're simply 
going to respect that instead of trying to work around it.

A user who has created a directory junction likely wants it to behave as if the 
directory is actually in that location. Similarly, a user who has created a 
directory symlink likely wants it to behave as if it were in that location. 
Powershell treats both the same for high-level operations - the LinkType 
attribute is the only way to tell them apart (mirrored in the st_reparse_tag 

> If we've opened the reparse point to test for a symlink, we must reopen for 
> all other types

The premise here is not true - we've opened the reparse point to get the file 
attributes. The only reason we look at the reparse tag at all is to raise an 
error if the user requested traversal and despite that, we ended up at a link, 
and I'm becoming less convinced that should be an error anyway (this is 
different from nt.readlink() and ntpath.realpath(), of course, where we want to 
read the link and return where it points).

nt.stat() is trying to read the file attributes, and if they are not accessible 
then raising is the correct behaviour, so I don't see why we should try any 
harder than the OS here.


Python tracker <>
Python-bugs-list mailing list

Reply via email to