Mail Archives: djgpp/2001/03/18/04:53:19
On Sun, 18 Mar 2001, David Graff wrote:
> I hope I'm sending this to the right address.
Yes, you are.
> 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.
This is expected behavior: __file_tree_walk walks the files one by one,
querying the filesystem about the next file when it is done with the
current one. It does _not_ read the files at once at the beginning. So
any files you add to the same tree hierarchy inside your filter function
will be seen by __file_tree_walk as well.
> I'm curious whether others are aware of this "feature" of __file_tree_walk
I'm aware ;-)
> (am I the first to ever try this sort of application?)
Actually, __file_tree_walk is used by the library function `rename' to
move a directory with all its subdirectories and files into a different
place. As such, it is very heavily exercised by many programs, GNU `mv'
being the most notable example.
As a matter of fact, __file_tree_walk was written because `rename'
required something like that.
> I think it deserves to be mentioned in the man/info page for this function, at
> least.
I'm unsure how would you like this to be documented. I don't think it is
easy to explain this without going into the details of a specific
implementation of the filter function, such as the one you used. Without
such specifics, a user would be confused by the docs rather than helped
by it.
- Raw text -