Martin v. Löwis <mar...@v.loewis.de> added the comment: The patch (v3) looks technically correct, with two minor issues: perhaps one should release the handle to kernel32 (not sure whether other code does it, or whether it matters), and I would inline the two new functions into their single callers.
That aside, I sense a bigger issue of getting stat/lstat correct. In the presence of symbolic links, stat(2) is supposed to look at the file that is being linked to, whereas lstat is supposed to look at the link itself. Currently, lstat and stat do the same thing on Windows, as the assumption was that there are no symbolic links, anyway (in which case lstat does indeed return the same as stat always). This assumption is no longer correct - so the two functions need to be separated. I don't know what the most efficient way is to do a real stat() on Vista - ideally, the Get* APIs would take a flag to follow links. If that doesn't work, we would need to resolve the link ourselves, and look at the file being referenced. Possible errors (on POSIX) for stat then are ENOENT (broken symlink), ELOOP (symlink loop), ENOTDIR (path component in symlink value is not a directory), and EACCESS (path component in symlink, or target file is not accessible). This is just FYI; we should raise the appropriate Win32 errors (and hopefully, we don't have to do it ourselves, anyway). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1578269> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
