Re: new mime detection approach



El mié, 14-01-2004 a las 19:37, Shahms E. King escribió:

> Well, one way to do it is have the metadata be stored by something like
> medusa (or another such metadata-indexing daemon).  I would imagine an
> absolute path lookup of a given file could be made faster than sniffing
> every file.

The metadata *needs* to be stored on the file system directly, be it on
files or on metafiles (streams, EAs, whatever you'd like to call it). 
Otherwise you'll hit consistency problems with much, much higher
frequency, and backing up metadata you unknowingly started depending
upon becomes much, much more complicated.

Not to say that Medusa wouldn't be a great place to *cache* that info. 
Indeed, Medusa is great software.

> 
> > Additionally a metadata-based system would mean any non-nautilus
> > operation on the file could make it drop the metadata, leave metadata
> > around forever, or make the metadata stale. It would also have problems
> > with read-only media and probably other complications.
> 
> Well, if we can get rid of fam/dnotify and replace it with a decent
> file-change notification system

just a note: the speed problems (millions of updates) does not lie
within fam, it's with dnotify.  I remember that it was possible to
disable dnotify, and then fam would revert to polling, which still is
faster than letting each app poll independently anyway.

>  that doesn't require an open file
> descriptor to monitor,

this would be great.

>  the indexing daemon can sniff the mime type when
> it gets a file-created event (or changed).  If it felt like updating the
> EAs (where appropriate) that would be doable, too.  This method does
> have the drawback of persistently storing the metadata rather than
> querying it only when required, so diskspace might be an issue.  Such a
> system could evolve into something that handled a lot of the current . .
> . "sticky" issues with files and applications.  I could imagine file
> indexers that handle pulling "extra" metadata from specific file formats
> (thumbnail?, .desktop files?).

Hans Reiser prototyped file "dissectors" or plugins for the file system
which did exactly that.  They let you have your cake and eat it too,
because they let the FS developer expose a clean, unified API for
metadata while also making it possible to keep the in-band metadata
updated.
-- 
	Manuel Amador (Rudd-O)
	GPG key ID: 0xC1033CAD at keyserver.net

Attachment: signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]