Date:	Mon, 6 Apr 1998 16:45:39 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Myknees <Myknees AT aol DOT com>
cc:	dj AT delorie DOT com, djgpp AT delorie DOT com
Subject:	Re: findfirst attrib parameter -- I must be missing something
In-Reply-To:	<9cd1c4e1.3528b8b9@aol.com>
Message-ID:	<Pine.SUN.3.91.980406163655.11505A-100000@is>
MIME-Version:	1.0

On Mon, 6 Apr 1998, Myknees wrote:

> I'm sorry, I don't understand.  In the example I posted, it seems like regular
> files that haven't been backed up are not being excluded.  Maybe I am
> misunderstanding "exclusion".  I was assuming that if a file has an attribute
> of 0x20 and that bit hasn't been specified in the call, then that file will be
> excluded from the results, i.e. findfirst/next will not find that file.

Your understanding is perfectly right; unfortunately, that of DOS and
Windows leaves a lot to be desired ;-).  To wit: Ralf Brown's Interrupt
List explicitly says that bits 0 (read-only) and 5 (archive) in the
attributes you pass to DOS function 4Eh (called by `findfirst') are
*ignored* when looking for files.  So you only can control the directory,
system, hidden, and volume label bits. 

If the libc docs doesn't say this clearly enough, then it should be 
amended.

The Windows 9X LFN API introduced a smarter function 714Eh which *does* 
support smarter (or shall I say, less buggy) file selection.  DJGPP's 
`findfirst' calls that function when LFN is available, but it doesn't let 
you use the additional functionality (for back-compatibility reasons).

If the additional functionality is required, you can always add another 
libc function, say `_lfn_findfirst', which will support all the options 
that 714Eh supports (hint, hint).

- Raw text -