Mail Archives: djgpp/2001/03/18/01:46:39
From: | "Alexei A. Frounze" <dummy_addressee AT hotmail DOT com>
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | Re: __file_tree_walk vs. files created by callback
|
Date: | Sun, 18 Mar 2001 01:45:20 -0500
|
Lines: | 65
|
Message-ID: | <991lfo$40cjl$1@ID-57378.news.dfncis.de>
|
References: | <200103180634 DOT f2I6Ywq14286 AT unagi DOT cis DOT upenn DOT edu>
|
NNTP-Posting-Host: | 209-130-218-124.nas1.roc.gblx.net (209.130.218.124)
|
X-Trace: | fu-berlin.de 984897849 4207221 209.130.218.124 (16 [57378])
|
X-Priority: | 3
|
X-MSMail-Priority: | Normal
|
X-Newsreader: | Microsoft Outlook Express 5.50.4133.2400
|
X-MimeOLE: | Produced By Microsoft MimeOLE V5.50.4133.2400
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
Reply-To: | djgpp AT delorie DOT com
|
why should that be a bug? the OS truly tells you about all available files.
isn't that perfect?
--
Alexei A. Frounze
alexfru [AT] chat [DOT] ru
http://alexfru.chat.ru
http://members.xoom.com/alexfru/
http://welcome.to/pmode/
"David Graff" <graff AT unagi DOT cis DOT upenn DOT edu> wrote in message
news:200103180634 DOT f2I6Ywq14286 AT unagi DOT cis DOT upenn DOT edu...
>
> 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 -