On Sun, Sep 6, 2020 at 5:23 AM Juan José Santamaría Flecha <juanjo.santama...@gmail.com> wrote: > On Sat, Sep 5, 2020 at 2:13 AM Andres Freund <and...@anarazel.de> wrote: >> > However, it looks like we might be missing a further opportunity >> > here... Doesn't Windows already give us the flags we need in the >> > dwFileAttributes member of the WIN32_FIND_DATA object that the >> > Find{First,Next}File() functions populate? >> >> That'd be better... > > > At first I did not see how to get DT_LNK directly, but it is possible without > additional calls, so please find attached a version with that logic. > > This version also drops the enum, defining just the macros.
Excellent. I'd like to commit these soon, unless someone has a better idea for how to name file_utils_febe.c. I think the following is a little mysterious, but it does seem to be what people do for this in other projects. It is the documented way to detect mount points, and I guess IO_REPARSE_TAG_MOUNT_POINT is either overloaded also for junctions, or junctions are the same thing as mount points. It would be nice to see a Win32 documentation page that explicitly said that. + /* For reparse points dwReserved0 field will contain the ReparseTag */ + else if ((fd.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) != 0 + && (fd.dwReserved0 == IO_REPARSE_TAG_MOUNT_POINT)) + d->ret.d_type = DT_LNK; Hmm, it's interesting that our existing test for a junction in pgwin32_is_junction() only looks for FILE_ATTRIBUTE_REPARSE_POINT and doesn't care what kind of reparse point it is.