:Kieren MacMillan wrote:
:> Hello, all you BSD hackers!
:>
:> A major change to the "file-folder-desktop" metaphor is long overdue,
:> and it seems to me that FreeBSD -- with Mac OS X as a large and growing
:> "child" -- is the perfect place to start the revolution... ;-)
:>
:> If anyone has seen Scopeware (<http://www.scopeware.com>), you'll know
:> the kind of thing I'm thinking of: a universal indexing system where
:> *any* file of *any* type in *any* location would be cross-referenced
:> (using metadata as well as content where possible) in one or more
:> "filters" or "streams".
:>
:> Is anybody working on such a fundamental change? If not, is there any
:> interest in starting such a project? I'm not the world's most
:> experienced programmer (mostly Java, some XML/XSLT, a little RealBASIC,
:> etc.), but I'm a good project manager and technical writer, if that
:> would help.
:>
:> [n.b. Please cc my email address in any responses, as I'm not currently
:> subscribed to the full mailing list.]
:>
:> Best regards,
:> Kieren MacMillan.
:
:This sounds like the filesystem from BeOS.
:You might want to check out OpenBeOS. (http://www.openbeos.org/)
:Last time I checked, their attempt to rewrite the original BeOS
:code under a free license had made some progress, especially the
:filesystem part.
:
:--
:R
How about an API like this:
fd = fstrack(basedir, flags, timestamp);
Return a descriptor which tracks changes described in <flags>
that occur in the specified directory <basedir> or any sub-directory
of that directory. Start the reporting stream at timestamp
<timestamp> (allows you to pick up where you left off), or 0
to start reporting at the current time.
flags:
FSTRACK_CREATE - File creations
FSTRACK_DELETE - File deletions
FSTRACK_TRUNC - File truncations
FSTRACK_UPDATE - File updates
FSTRACK_CLOSE - File close() (last close() on file)
Returns -1 and ELOSTQUEUE if data related to the specified
timestamp has already been discarded by the kernel.
n = read(fd, buf, sizeof(buf))
Load as many tracking records as can be made to fit in the specified
buffer. If the buffer is too small to hold the next ready tracking
record, return -1 and EBUFTOOSMALL, the call can be remade with a
larger buffer.
May return a consolidation record if the kernel was forced to
throw away data due to a queue overflow. A conslidation record
is something like "One or more files in directory <blah> changed"
instead of "File XXX in directory <blah> changed".
Something like the above would be an incredibly powerful and capable
tool. It could be made to support kqueue() and select() as well.
Any sort of indexing or tracking of this magnitude would really have
to be a userland process, with support from a kernel mechanism. The
biggest problem with a kernel mechanism of this sort is going to be
queue overruns (say someone does an 'rm -rf' on a large directory).
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
