Request for breaking hard feature freeze for an important Nepomuk service

Martin Konold martin.konold at
Tue Jul 1 01:19:51 BST 2008

Am Montag 30 Juni 2008 schrieb Sebastian Trüg:

Hi Sebastian,

> * I have no replacement for inotify on Windows or MAC yet (KDirWatch cannot
> be used for the same reason as FAM)

are you aware of
FindFirstChangeNotification(__in  LPCTSTR lpPathName, __in  BOOL 
bWatchSubtree, __in  DWORD dwNotifyFilter); ?

To my knowledge this feature depends on support from the underlying filesystem 
though NTFS is well supported. I verified it once that it works with local 
NTFS. Networked drives need to be investigated (maybe check with Samba).
gives a hint that notification is actually part of the CIFS API.

The well known FileMon for Windows Utility (from former Sysinternals)
is able to watch local and networked resources including UNC resources.

IIRC FileMon needs Administrator privileges though.

It must be noted that certain versions of Microsoft Windows already provide 
analogous features, with some differing aspects. The NTFS Change Journal 
provides a persistent file system change log. When file system objects are 
added, deleted, or modified, the change is recorded in a per-volume journal. 
In particular, Microsoft uses this mechanism for implementing the Indexing 
Service feature of Windows XP Professional.
"The Windows 2000 Change Journal is a database that contains a list of every 
change made to the files or directories on an NTFS 5.0 volume. Each volume 
has its own Change Journal database that contains records reflecting the 
changes occurring to that volume's files and directories."

For Macs there is a similiar mechanism which needs also root permissions and
which is used by Spotlight. To my knowledge the Mac API to this kernel 
functionality is not published. AFAIK it is subject to change in the future 
(a more mature API is planned)

see also:

An older Mac method is to use kqueue, kevent -- kernel event notification 

IMHO the kqueue approach is really inefficient for your purposes as it 
requires to keep to many filedescriptors open and does not really provide the 
required information in order to figure out the real cause for the event 
without scanning.

-- martin

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126

More information about the kde-core-devel mailing list