KDirWatch emitting dirty signal many times for one change

[Sébastien Laoût]

> Currently, KDirWatch can not notify you about file renaming because it simply 
> has no signal to notify renamings. Perhaps it's the best to add rename 
> notification to KDirWatch, especially since DNOTIFY and FAM indeed seem to 
> support it (for KDE 3.3, we could add a method returning a RenameNotifier 
> helper object that can emit this signal).

OK.
Would be fine.
Seem quite complicated (why do not simple emit a fileRenamed() instead
of create new objects and... thinks I don't understand).
But it's fine.

> Your try to detect renaming with delete/create sequences can't work in a 
> reliable way for all installations. Better don't assume it to work.

Erf.

> For meta information, you should use extended file attributes instead
> (KDE has already an interface for this (?)).

Extended file attributes ?
Never read this !
Is it well spreaded ?
Is it the thing that is in the new Linux 2.6 ? To manage rights for instance ?
Or on some FileSystem only ?

Hum... To be clearer, my program is BasKet :
http://les83plus.fr.st/sebastien.laout/basket
So : for the moment it works very well.
I store items (text, html and images, not links nor colors) in files.
Each basket store a group of items.
And I have a .basket XML file per basket (and one folder per basket).
This file store each item properties (and position, and content for link
and color items, that do not need save file).
The meta-data are : "bool checked", "string runCommand" and
"longString annotations".
The last one can be a very long text !!!!!!!!!!
Is this supported by "extended file attributes" ?
And what happens if a file go out of range of my app : meta-data are
keped in file... Can be compromosing (see the MS Word versionning
feature).

And how does KDesktop ?
Is it support well renamings ?
Or is it storing positions in "extended file attributs" ?
I think no...

> As you see, notification of file changes is an OS issue. But KDE is not bound 
> to one OS (i.e. Linux). And as different OSes provide different ways to 
> notify file changes, we have to support these. More difficult are network 
> file systems, as the protocol has to include these. I don't think that NFS or 
> SAMBA notify about file renames.

Hum... OK.
How does Windows handle this issue ?
Is this working under Windows ?
I think yes : it's Windows (only one API, OS and GUI layers are
mixed...).
Is anyone tried ?

> Currently, we support the following ways:
> * STAT: If an OS does not provide any file change notifications at all (as was 
> the case with Linux until around 2.4.17), the only way is to periodically to 
> a stat() system call on files to see changes. There is no way to detect 
> renames reliable, but we could come up with some heuristics (e.g. check for 
> same inode number and same file attributes like size).
> * DNOTIFY: Notifications from the Linux OS via signals for open file 
> descriptors of directories.
> * FAM: Notifications from a local daemon via sockets. This daemon originally 
> came with IRIX (Unix version from SGI), and was open-sourced. This spread its 
> use under Linux. The daemon on IRIX originally used a OS service called imon 
> (Inode Monitor), which was ported to Linux but never found its way into the 
> standard Linux Kernel Tree. Instead, nowadays the FAM daemon often uses 
> DNOTIFY, but sometimes stat()'s. The advantage of FAM: It works around NFS 
> not being able to reliable notify file changes (?): If a directory is mounted 
> via NFS, the FAM daemon tries to connect to a remote FAM daemon on the NFS 
> server, to get file change events from the server in a reliable way.

Thank you for this very complete summary.
I have it better in mind, now !

I will have a brainstorming and see what can I do.
I hope I will find a solution.