From: Myknees 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 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Precedence: bulk DJ Delorie 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)