From:	Myknees <Myknees AT aol DOT com>
Message-ID:	<9cd1c4e1.3528b8b9@aol.com>
Date:	Mon, 6 Apr 1998 07:12:54 EDT
To:	dj AT delorie DOT com
Cc:	djgpp AT delorie DOT com
Mime-Version:	1.0
Subject:	Re: findfirst attrib parameter -- I must be missing something

DJ Delorie <dj AT delorie DOT com> writes:
>> That implies that the regular files meet the qualification for exclusion.
>>The
>> regular files have flag bits (0x20).  So the regular files do have a flag
>>bit
>
>No, regular files that haven't been backed up (archived - FA_ARCH) are
>excluded.  Writable regular files that HAVE been backed up have an
>attribute byte of zero, and thus always meet the selection criteria
>for findfirst().

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.

As far as FA_ARCH goes, I guess you are talking about the attribute bit that
compression utilities use.  I haven't backed up the files that are showing up
when I use the findfirst(files, &f, FA_DIREC) and findnext(&f) calls, and they
have attributes of 0x20 and 0x10, but not zero.  It seems that they are
regular files that haven't been backed up, but they are not being excluded.  I
do see findfirst/next acting as john R. Latala describes, but I don't see how
that matches the docs.  

--Ed (Myknees)

- Raw text -