Date: Sun, 12 Jan 2003 13:34:08 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Roger 'Rocky' Vetterberg" <listsub@401.cx> Cc: Kieren MacMillan <kmacmillan@coresolutions.ca>, freebsd-hackers@FreeBSD.ORG Subject: Re: anyone working on a new file system metaphor? Message-ID: <200301122134.h0CLY8DW021177@apollo.backplane.com> References: <0747734E-24B5-11D7-9116-00306572DA52@coresolutions.ca> <3E21D4C6.9020108@401.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
: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 <dillon@backplane.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301122134.h0CLY8DW021177>