Fixes uv_fs_stat and uv_fs_lstat returning EINVAL when invoked on a
non-symlink reparse point.
1. Only tries to read symlinks when invoked via lstat (do_lstat == 1).
Rationale is that only lstat can set S_IFLNK because when a file is
tested by stat, symlinks are resolved by the OS and the returned file
must be real. Note that broken symlinks fail at CreateFile.
FILE_ATTRIBUTE_REPARSE_POINT is used by filesystem drivers for purposes
besides symlinks, and uv_fs_stat fails when invoked on these files
because fs__readlink_handle returns ERROR_SYMLINK_NOT_SUPPORTED. By
ignoring the attribute in uv_fs_stat, these files are now handled
correctly.
2. Modifies the logic added to fs__stat_handle to fix#995 as follows:
A failed fs__readlink_handle on a file with a reparse point indicates
that the file is not a symlink. The fix for #995 added code to fall
through and behave as with a normal file in this case. However, this is
not correct because lstat had opened the file with
FILE_FLAG_OPEN_REPARSE_POINT, preventing the filesystem from acting
based on the reparse point contents.
The fix makes fs__stat_handle fail back to the higher level
fs__stat_impl, which sets do_lstat to 0 and re-opens the file without
FILE_FLAG_OPEN_REPARSE_POINT, allowing normal filesystem processing to
take place.
This is also a slightly cleaner solution as symlink fallback is only
handled in one place (fs__stat_impl) instead of two (fs__stat_impl and
fs__stat_handle).
Note that the error tested in the fix for #995,
ERROR_NOT_A_REPARSE_POINT, is not actually returned by Windows in the
case of a non-symlink reparse point. I attempted to reproduce the error
by repeating the test steps in the issue but failed. However, the the
fix logic is preserved out of caution.
3. Adds tests to fs-test.c for the above two changes.
Thorough testing requires some non-trivial setup - like an OSX computer
on the LAN or a custom filesystem driver - so these tests are left
commented out for manual invocation.
PR-URL: https://github.com/libuv/libuv/pull/1522
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
1d9c13f1f7