[PATCH] fix #47996

[Josef Weidendorfer]

On Thursday 07 November 2002 15:29, Michael Brade wrote:
> On Thursday 07 November 2002 14:01, Josef Weidendorfer wrote:
> ...
> > Of course when a program writes a large file, and DNOTIFY is used in FAM,
> > you will get a signal for every write() system call for that file :-(
>
> I see.

It seems that we should have support for event delaying in the kernel...

I once suggested a work around if the copying is controlled by KDE:
Do it in an unwatched directory (e.g. in directory ".hidden/" of the target 
dir) and then do a move. We need another directory as with DNOTIFY and
FAM you simply can't say that some files shouldn't be watched. KDirLister even 
could ignore this directory to the user if he wants to see hidden files.

When doing a "recursive" watch, these ".hidden" dirs shouldn't get watched.

> > 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?

> > 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() ?
>
> 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.

The different semantic among FAM and the other methods was simply added for 
convenience (because we get the file change event, why not use it?). The 
correct way for FAM is to NOT notify on file changes when "watchFiles" is 
false.
This is undoubtly a semantic change for FAM. I don't know if this change will 
give compatibility problems. 
I only can imagine a user with KDELIBS 3.2 and a KDE 3.0/1 program using 
KDirWatch directly and depending on file change notifications when FAM is 
switched on... But this program can't know that FAM is used, so what?

> > I get these from FAM, and once "watchFiles" is implemented, it is easy to
> > generate the signals in STAT/DNOTIFY mode, too.

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.

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 ?!?

I suppose adding a "fileExist" signal won't hurt. And can be added for KDE 3.2 
without BC problems (as Simon pointed out).

> 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.
I don't think it has any negative effects for a class if you add signals: You 
don't have to use them. Of course the existing signals won't be touched for 
compatibility reasons.

Josef