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).