Message-Id: <200103180634.f2I6Ywq14286@unagi.cis.upenn.edu>
X-Mailer: exmh version 2.1.1 10/15/1999
To: djgpp AT delorie DOT com
cc: graff AT unagi DOT cis DOT upenn DOT edu
Subject: __file_tree_walk vs. files created by callback
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 18 Mar 2001 01:34:58 -0500
From: David Graff <graff AT unagi DOT cis DOT upenn DOT edu>
Reply-To: djgpp AT delorie DOT com


I hope I'm sending this to the right address.

I am using a recent (Feb.2001) download of djgpp on a w98 system, and my 
particular use for __file_tree_walk is:

   ...
   __file_tree_walk( base_path, filter_func );
   ...

int filter_func( const char *fspec, const struct ffblk *ff )
{
 /* if fspec refers to a data file, and the contents of this file meet
  * certain conditions, come up with a modified copy of fspec, and use this
  * new name to create a new output file in the same directory as fspec;
  * pass the contents of fspec to the new file (with some modifications),
  * then close both files
  */
}

What I notice when I run this sort of application, is that during a single 
run, __file_tree_walk finds all the old files that existed when the process 
started, and then also finds all the new files that have just been created by 
the preceding iterations of filter_func(), and these are dutifully passed to 
filter_func() as well.  The callback ends up recursing on its own output.

Obviously, there is a work-around: make sure the callback knows how to 
recognize files that it has created, and/or take other steps to safeguard 
against "too much" recursion within a single directory.

I'm curious whether others are aware of this "feature" of __file_tree_walk (am 
I the first to ever try this sort of application?), and whether it should be 
considered a "bug" (this was my initial reaction, but then I realized that 
this is probably a very natural mode of operation, which would be very hard to 
change).

I think it deserves to be mentioned in the man/info page for this function, at 
least.  Thanks.

	Dave Graff