[Patch] Add dirent.d_type support to Cygwin 1.7 ?
Thu Nov 27 11:15:00 GMT 2008
On Nov 27 11:38, Christian Franke wrote:
> Hi Corinna,
> Corinna Vinschen wrote:
> > Shouldn't this condition test positively instead like, say,
> > !(attr & (FILE_ATTRIBUTE_REPARSE_POINT | FILE_ATTRIBUTE_DEVICE))
> If any undocumented flag is set, then DT_UNKNOWN should be returned. MS
> might invent new flags, at least on the ntdll layer.
Hmm. That's the question. Should we treat new flags as being harmless,
or should we treat them as dangerous?
For instance, if we had done that years ago, before FILE_ATTRIBUTE_ENCRYPTED
had been invented, we would have set all encrypted files to DT_UNKNOWN
later on, until Cygwin would have been rebuilt with a newer winnt.h.
OTOH, DT_UNKNOWN is practically nothing worth to get headaches about.
It just potentially slows down find and ls to the state before inventing
d_type. So, yeah, I guess it's ok to treat new attributes as
potentially dangerous here.
> Meantime, I found FILE_ATTRIBUTE_VALID_FLAGS in winnt.h. It does not
> include FILE_ATTRIBUTE_DEVICE.
> I would suggest the following logic:
> if (attr)
> if (attr & ~FILE_ATTRIBUTE_VALID_FLAGS)
> /* undocumented flag: DT_UNKNOWN
> Probably print a warning once:
> "... please inform cygwin at cygwin.com" */
> else if (!(attr & (FILE_ATTRIBUTE_SYSTEM
> /* DT_REG or DT_DIR */
> /* possible old symlink or something special: DT_UNKNOWN */;
The logic sounds ok to me. I just don't think we need a warning
and the condition could be simplified accordingly.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
More information about the Cygwin-patches