Re: Recursive modified-timestamp?

["Alexander G. M. Smith" <agmsmith@rogers.com>]

Fred Schaettgen wrote on Sat, 1 Jan 2005 01:43:48 +0100:
> The file system itself could help for instance by providing a new 
> "change-monitor"-flag for a file. This flag would be set only from userspace 
> and reset when the file is modified. If the flag is still set when the file 
> is being modified, the filesystem would then create a symlink or something 
> like for the file in a special directory.

That reminds me that the other thing BeOS had was a change notification
system using messaging.  If you requested monitoring of a directory or
file (with flags to say which kind of changes are of interest) then
it would send your program a BMessage with the details (such as a file
being added to a directory).

This was also extended to monitor changes to the indices: you gave it a
query expression and the kernel/file system then would send notification
messages if a change to a file (or its attributes) added or removed that
file from the set of files matching the query.  Seems like a lot of
overhead, but it wasn't that noticable and did make the OS a lot more
useful (cooler too, directory windows or even complex Find results were
always up to date even as files changed).

But I don't think that's quite what you wanted (and isn't as economical
as your tree of percolated up modification times).  Though it would be nifty
(but useless?) to have a build system (make-like) operating in real time -
change a source file and the system automatically recompiles it immediately.

> Moving too much logic into the file system has lots of drawbacks. It
> makes the file system complicated, so it will be less likely to be
> implemented at all.

True.  That's why I think query evaluation should be outside the file
system, with just the indices in the kernel / file system API.  But
that's another story.

- Alex