[Python-Dev] Updates to PEP 471, the os.scandir() proposal (original) (raw)
Paul Moore p.f.moore at gmail.com
Thu Jul 10 09:04:53 CEST 2014
- Previous message: [Python-Dev] Updates to PEP 471, the os.scandir() proposal
- Next message: [Python-Dev] Updates to PEP 471, the os.scandir() proposal
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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/NTFSsymboliclink ... 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). 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.
Paul
- Previous message: [Python-Dev] Updates to PEP 471, the os.scandir() proposal
- Next message: [Python-Dev] Updates to PEP 471, the os.scandir() proposal
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]