Hi,
Am Donnerstag, den 07.10.2004, 00:09 -0400 schrieb Curtis Hovey:
> On Wed, 2004-10-06 at 16:49 +0200, Alexander Larsson wrote:
> > On Wed, 2004-10-06 at 15:51 +0200, Danny Milosavljevic wrote:
[...]
> > > gnome_vfs_get_file_info() -> containing metadata as name->value
> > > hashtable ? Or something more sophisticated ?
> >
> > The problem is not to just expose the current API. We want to completely
> > redo it so it doesn't depend on nautilus, gets good performance, is
> > race-free, can be backed by EA filesystem support etc.
> >
> > Basically, it requires a lot of thinking and designing.
>
> The EA support is a bugbear. Not every filesystem a user interacts with
> supports EAs: SMB, NFS, FAT, etc.... Data like icons and emblems are
> naturally EAs.
How about if the filesystem doesnt support them, we don't either? I
don't see any serious disadvantage of that, but it sure gives incentive
to add EA support to said filesystems (which is the right thing to do
imo, rather than emulating).
[or, if impossible, move the EA emulation into the kernel; I'm sure for
that comment I will get added to the horrible-death-list of some kernel
people now ;)]
On a side note, actually conceptually I like the reiserfs approach even
better than EA api, since its more logical and (ideally) doesn't require
any api extensions: Metadata goes to a "subdirectory" of the file (not
to a subdirectory of the directory of the file, but literally to a
subdirectory of the file), like that,
$ cat /home/dannym/rule-the-world.txt/emblem.important
1
And it would have mtime and permissions per attribute entry too, without
any extra hassle.
(obviously for attributes of directories that wouldnt work quite the
same ;))
> Our solution requires something like a filesystem/EA
> agnostic repository. Keeping it synced with a filesystem will be a
> pain.
Yeah, that will be fragile as hell. But if we just emulate EAs for
filesystem that dont support EAs, it shouldnt be that bad ("only"
migration problems when the fs is switched from/to EA-capable,
permission problems for the paranoid, rather slow EAs, fragmented
distant EA and real data - not a real serious issue imo.)
>
> Would a metadata repository be standalone? Could it be in E-D-S?
If EAs were to be emulated too it wouldnt be feasible to have it completely standalone since EA change notifications would be expensive (everytime one
EA changes, the metadata storage file for the directory - or whatever granularity - changed and the file manager would have to scan the entire metadata storage file,
eeew)
This is evil.
Anyways, we need to get it working somehow :)
cheers,
Danny
--
www.keyserver.net key id A334AEA6
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil