From owner-freebsd-hackers Sun Jan 12 13:34:16 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41CF137B401 for ; Sun, 12 Jan 2003 13:34:14 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4C7F43F3F for ; Sun, 12 Jan 2003 13:34:13 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0CLY8Yp021178; Sun, 12 Jan 2003 13:34:08 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0CLY8DW021177; Sun, 12 Jan 2003 13:34:08 -0800 (PST) Date: Sun, 12 Jan 2003 13:34:08 -0800 (PST) From: Matthew Dillon Message-Id: <200301122134.h0CLY8DW021177@apollo.backplane.com> To: "Roger 'Rocky' Vetterberg" Cc: Kieren MacMillan , freebsd-hackers@FreeBSD.ORG Subject: Re: anyone working on a new file system metaphor? References: <0747734E-24B5-11D7-9116-00306572DA52@coresolutions.ca> <3E21D4C6.9020108@401.cx> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :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 (), 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 that occur in the specified directory or any sub-directory of that directory. Start the reporting stream at 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 changed" instead of "File XXX in directory 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message