Open vasama opened 1 year ago
@strega-nil-ms
The error code is 1920 ("The file cannot be accessed by the system.") on my machine, reported by CreateFileW
.
Can we just return true
when error code 1920 (and it friends) is encountered?
Does std::filesystem::exists
even call CreateFileW
? If so, it should not -- should use GetFileAttributesW
or FindFirstFileW
.
Does
std::filesystem::exists
even callCreateFileW
? If so, it should not -- should useGetFileAttributesW
orFindFirstFileW
.
It must, because for some reason, unix sockets are considered reparse points. I'm not sure how to solve this, to be quite honest. This seems to be a failing of the standard's interaction with Windows' APIs.
We talked about this at the weekly maintainer meeting. Nicole debugged into this and says that the problem is happening here:
This is where __std_fs_get_stats()
calls CreateFileW()
(via _Fs_file
). It appears that we need to do something like add extra logic here to detect reparse points, and then to further detect Unix sockets. From quickly searching MSDN Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/fileio/reparse-point-tags mentions something that looks like it might be relevant: IO_REPARSE_TAG_AF_UNIX
resembles the AF_UNIX
used in the repro (which curiously isn't mentioned in WSASocketW
documentation).
This would add extra calls to the filesystem::exists()
codepath, but we currently don't see a better way to avoid this, if we want to handle this aspect of the filesystem.
We might want to ask internal mailing lists (e.g. win32prg) if there's some better way to achieve this with the public APIs that we can use.
You may just need to use IsReparseTagNameSurrogate
on the reparse tag to test if it's some kind of link or not.
Description
std::filesystem::exists(p)
, wherep
is a path pointing to a unix socket (e.g.p = "./test.sock"
), throws an exception with the messageexists: unknown error: "./test.sock"
.Command-line test case
Expected behavior
I expect the call to
std::filesystem::exists
to return true.STL version