From: Myknees <Myknees AT aol DOT com>
Message-ID: <75cd94d4.352966c0@aol.com>
Date: Mon, 6 Apr 1998 19:35:25 EDT
To: eliz AT is DOT elta DOT co DOT il
Cc: djgpp AT delorie DOT com, dj 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

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> writes:
> 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.

There is a patch at the bottom of this post that reflects what has been said
here.

> 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).

How exactly would one go about doing that?  

proposed changes to findfirst documentation:
============
*** findf_old.txh	Mon Apr  6 18:06:30 1998
--- findfirs.txh	Mon Apr  6 19:18:32 1998
***************
*** 19,25 ****
  
  @item FA_RDONLY
  
! Include read-only files in the search
  
  @item FA_HIDDEN
  
--- 19,25 ----
  
  @item FA_RDONLY
  
! Include read-only files in the search (Ignored.)
  
  @item FA_HIDDEN
  
***************
*** 39,52 ****
  
  @item FA_ARCH
  
! Include modified files in the search
  
  @end table
  
! Any file that doesn't have any flag bits that aren't specified is
! selected for the search.  Thus, if you specified @code{FA_DIREC} and
! @code{FA_LABEL}, you would get all subdirectories, the volume label, and
! any file that is neither read-only or modified. 
  
  The results of the search are stored in @var{ffblk}:
  
--- 39,59 ----
  
  @item FA_ARCH
  
! Include modified files in the search (Ignored.)
  
  @end table
  
! If a file has flag bits that are not specified in the @var{attrib}
! parameter, the file will be excluded from the results.  Thus, if you
! specified @code{FA_DIREC} and @code{FA_LABEL}, subdirectories and the
! volume label will be included in the results.  Hidden and system files
! will be excluded.
! 
! Since @code{findfirst} calls DOS function 4eh, it is not possible to
! exclude read-only files or archive files from the results.  Even if
! the FA_ARCH and FA_RDONLY bits are not specified in the attrib
! parameter, the results will include any read-only and archive files in
! the directory searched.   
  
  The results of the search are stored in @var{ffblk}:
  
***************
*** 69,75 ****
  
  @example
  struct ffblk f;
! int done = findfirst("*.exe", &f, FA_ARCH|FA_RDONLY);
  while (!done)
  @{
    printf("%10u %2u:%02u:%02u %2u/%02u/%4u %s\n",
--- 76,82 ----
  
  @example
  struct ffblk f;
! int done = findfirst("*.exe", &f, FA_HIDDEN | FA_SYSTEM);
  while (!done)
  @{
    printf("%10u %2u:%02u:%02u %2u/%02u/%4u %s\n",