[PATCH] fix #47996

[Michael Brade]

On Thursday 07 November 2002 18:09, Josef Weidendorfer wrote:
> > > Regarding the little number of signals in KDirWatch:
> > > I don't feel guilty. When I introduced explicit file watching before
> > > KDE 3.0, I added separate signals. Short before the KDE 3 API freeze it
> > > was decided to unify the signals for simplified usage.
> >
> > I know. IIRC it was me who suggested to reduce the number of signals...
> > at that time I didn't know about the possibility of being flooded with
> > events.
>
> So further signals are unneeded if event merging and delaying is done in
> KDirWatch?
Yes, I think so. However, see below.

> > > For KDE 4: Do you think it has an advantage to have a "fileExists"
> > > signal, emitted for all existing files in a directory after a addDir()
> > > ?
Oops, got it now. But that would mean we don't need the KIO::listDir() as we 
could theoretically use the files emitted after addDir() ;-) Seems to be 
superfluous to me...

> > Hmm. What do you mean with fileExists? My problem ATM is that with STAT I
> > get a signal for a directory registered with addDir which means "a file
> > in this directory was changed", so I need to rescan the whole directory.
> > When using FAM I get the same signal, however, now it means "exactly this
> > file has changed".
>
> There will be no difference at all if "watchFiles" is implemented. You will
> have to set this to "true" for KDirLister, and FAM/STAT/DNOTIFY will all
> tell the same.
Perfect. That will remove quite a bit of slow code.

> The "fileExists" events could be used for keeping track of existing files
> in a directory. You always will have the view of KDirWatch (and thus, FAM)
> about the existing files.
> ATM, a KDirWatch user could make the mistake to first look for existing
> files itself and afterwards switching on dir watching. He could miss the
> creation of a file: Say the app scans a dir; afterwards a file is created;
> afterwards FAM registers the dir watch. FAM will not send a "created"
> signal as the file is already existing. And the app doesn't know about the
> new file.
>
> This race can't happen if you use the "fileExists" event.
Or if you use KDirWatch correctly. I don't think we have to work around 
KDirWatch misusage, a developer (!) should know what he is doing. I'd rather 
add this to KDirWatch's docu.

> Thinking a little bit about this race: I suppose it can even happen ATM.
> Suppose a NFS directory. The app uses NFS, FAM uses the remote FAM server.
> Both services are asynchronous. And the order of requests could be
> reversed. Thus the race is possible ?!?
Hmm..? Ahh, but there's no way to work around this I guess? (And not that 
common to happen, IMHO)

> I suppose adding a "fileExist" signal won't hurt. And can be added for KDE
> 3.2 without BC problems (as Simon pointed out).
I'm not sure about it's usefulness, as I said already. IMHO, it can really 
slow your app down unneccessarily.

> > And to answer you other mail: it's not neccessary to have _6_ signals,
> > created() can emit a directory or a file, not important at all. For
> > deleted() it may be nice to know if it is a directory or not, but not too
> > important either. This simply doesn't happen really often.
>
> But on the otherside: Different signals for files and dirs are a service to
> the user, and the user has to add code to distinguish itself, which could
> introduce more bugs.
s/introduce/prevent/, right? Yes, I agree, it can't hurt.

-- 
Michael Brade;                 KDE Developer, Student of Computer Science
  |-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
  °--web: http://www.kde.org/people/michaelb.html

KDE 3: The Next Generation in Desktop Experience

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021110/bf865b2a/attachment.sig>