Mail Archives: djgpp/2001/03/18/01:37:14
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
- Raw text -