Date: Mon, 6 Apr 1998 16:45:39 +0300 (IDT) From: Eli Zaretskii To: Myknees 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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).