KDirWatch emitting dirty signal many times for one change

[Josef Weidendorfer]

Am Tuesday 13 April 2004 19:34 schrieb Sébastien Laoût:
> Le mar 13/04/2004 à 12:56, Waldo Bastian a écrit :
> > There is no reliable way to get this information. When the user
> > renames the file in konqueror or with KDesktop you will get the
> > signals that David mentioned, but when the user renames the files
> > on the command line the only information that KDirWatcher gets is
> > that one file disappeared and that another one appeared at roughly
> > the same time.
>
> Pff... All my 0.4.x TODO points are fall down to water, now !

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).
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.
For meta information, you should use extended file attributes instead (KDE has 
already an interface for this (?)).

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.

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.

Josef