After pulling the error fixes, rm **/config.cache, and re-making, I got some
funny results while rebuilding cygwin32 only.
Some previously built object files were no longer recognized as such, and halted
the build; even file showed them as generic "data".
This persisted even after rm
There are two Windows system calls that currently fail with
STATUS_IO_REPARSE_TAG_NOT_HANDLED when called on an AF_UNIX socket: a
call to NtOpenFile in get_file_sd and a call to NtCreateFile in
fhandler_base::open.
Fix this by adding the FILE_OPEN_REPARSE_POINT flag to those calls
when the file
I'll push these in a few days if no one sees anything wrong. Corinna,
please check them when you return.
Ken Brown (3):
Cygwin: AF_UNIX: use FILE_OPEN_REPARSE_POINT when needed
Cygwin: fix handling of known reparse points that are not symlinks
Cygwin: always recognize AF_UNIX sockets as
If __WITH_AF_UNIX is defined when Cygwin is built, then a named
AF_UNIX socket is represented by a reparse point with a
Cygwin-specific tag and GUID. Make such files recognizable as reparse
points (but not as sockets) even if __WITH_AF_UNIX is not defined.
That way utilities such as 'ls' and 'rm'
Commit aa467e6e, "Cygwin: add AF_UNIX reparse points to path
handling", changed check_reparse_point_target so that it could return
a positive value on a known reparse point that is not a symlink. But
some of the code in check_reparse_point that handles this positive
return value was executed
