Le 18 déc. 05 à 22:19, David Chisnall a écrit :
I had a look at this about a year ago. KQueue/KEvent on Free/
NetBSD allowed you to watch a single file / folder, but this
limited you to 1024 watched files per process (each file required
an open file descriptor).
Linux had inotify, which had the same limitation.
Not exactly…
dnotify has, but not inotify which supercedes it. inotify doesn't
need open file descriptors. It has been created in part to remove
this limitation and to work with both files and directories, dnotify
was only usable to watch directories.
However I have checked inotify documentation and I have discovered it
doesn't support recursive notifications unlike what I wrote in a
previous mail :-/. That sucks because it is currently limited to 8192
watches per device (you need a watch structure for each path) which
means you cannot a monitor a whole file system since no more than 8
devices are allowed. Take note that device files are used by inotify
to report inode events.
I suppose Beagle or Kat are currently working around this 65536
watched directories limit by resorting on selective file system
crawling when the limit is reached. That's probably ugly :-)
iirc Beagle only index home directory at this time to avoid the issue.
On OS X there was an undocumented system call 'searchfs,' which
allowed you to quickly search based on file system metadata, so you
could (for example) poll every n seconds for all files with access
times more recent than n seconds ago. This only really worked on
HFS+ (which stores metadata in B+ trees separate from the inodes,
unlike UFS-like filesystems, which store them on the inodes), but
it did more or less work.
Do you think this is what Apple is relying on at kernel level to
report files related events to Spotlight indexer ?
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
