[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: Moving away from app-centric mimetypes (e.g. kword)
From:       "Friedrich W. H. Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2002-05-20 14:14:10
[Download RAW message or body]

Mariusz Pekala schrieb:
> 
> On Wed 15 May 2002 00:24, Friedrich W. H. Kossebau wrote:
> > > The disadvantages are that, if you move or rename a file, you lose the
> > > metadata. But since this is a Proof Of Concept, and not a perfect
> > > implementation, perhaps we can live with that limitation in the short
> > > term.
> >
> > Most of my renaming and moving of files is done these days in konqueror
> > so if it has support there should be no loss. And for command line there
> > could be an alias for "mv" etc that invokes a script doing things that
> > are nessecary to keep metadata consistent.
> 
> Personally, I don't like the concept of an alias. You suggest I HAVE to have
> it to keep the system working properly?

It's just a proposed workaround for the commandline until
metadata/extended attributes are fully handled by the filesystems... no
need not use it ;), but are there alternative solutions? 

> For people using unix-like filesystems the identifier of a file is not it's
> name but it's i-node number. Bind metadata not to a name, but to i-node and
> you're safe to rename file. This does not solve the 'copy' problem, anyway.

Don't have that much experience with file system access APIs and might
have just overseen it: Is there a way to determine a file's inode
number? E.g. in which lib for C or C++, with which calls?

And a rename/move from one filesystem to another breaks the i-node
number identifier, doesn't it?

Friedrich

[prev in list] [next in list] [prev in thread] [next in thread]