On 10 July 2014 17:04, Paul Moore <p.f.mo...@gmail.com> wrote: > On 10 July 2014 01:23, Victor Stinner <victor.stin...@gmail.com> wrote: > >> As a Windows user with only a superficial understanding of how > >> symlinks should behave, (...) > > > > FYI Windows also supports symbolic links since Windows Vista. The > > feature is unknown because it is restricted to the administrator > > account. Try the "mklink" command in a terminal (cmd.exe) ;-) > > http://en.wikipedia.org/wiki/NTFS_symbolic_link > > > > ... To be honest, I never created a symlink on Windows. But since it > > is supported, you need to know it to write correctly your Windows > > code. > > I know how symlinks *do* behave, and I know how Windows supports them. > What I meant was that, because Windows typically makes little use of > symlinks, I have little or no intuition of what feels natural to > people using an OS where symlinks are common. > > As someone (Tim?) pointed out later in the thread, > FindFirstFile/FindNextFile doesn't follow symlinks by default (and nor > do the dirent entries on Unix).
It wasn't me (I didn't even see it - lost in the noise). > So whether or not it's "natural", the > "free" functionality provided by the OS is that of lstat, not that of > stat. Presumably because it's possible to build symlink-following code > on top of non-following code, but not the other way around. > For most uses the most natural thing is to follow symlinks (e.g. opening a symlink in a text editor should open the target). However, I think not following symlinks by default is better approach for exactly the reason Paul has noted above. Tim Delaney
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
