On Sun, Sep 6, 2020 at 5:23 AM Juan José Santamaría Flecha
<juanjo.santamaria@gmail.com> wrote:
> On Sat, Sep 5, 2020 at 2:13 AM Andres Freund <andres@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
attacheda 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.
