Re: Moving away from app-centric mimetypes (e.g. kword)
"Friedrich W. H. Kossebau" <[email protected]> Mon, 20 May 2002 16:14:10 +0200
| Newsgroups | gmane.comp.kde.look |
|---|---|
| Message-ID | <[email protected]> |
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