On 10 July 2014 17:04, Paul Moore <p.f.moore at gmail.com> wrote: > On 10 July 2014 01:23, Victor Stinner <victor.stinner at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140710/20b8f992/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4