Re: Metadata support
Re: Metadata support
- Subject: Re: Metadata support
- From: Q <email@hidden>
- Date: Mon, 26 Jun 2006 20:34:42 +1000
On 26/06/2006, at 11:02 AM, Jordan K. Hubbard wrote:
I think there's been a lot of confusion here about what constitutes
"file metadata".
First off, the ownership/mode/{creation,access} time and other
inode specific data is POSIX-layer stuff and there already exist [l]
stat(2) interfaces for getting this information, so sticking it in
the EA list would be double-entry bookkeeping at best and confusing
at worst.
Agreed.
Second, you can hardly include "3rd party housekeeping" info like
Finder's .DS_Store data in the same category since that's just some
other application's view of the file, it's not data specific to the
file itself. Another instance of that would be spotlight's index
data for the file - would you have that associated with the file
too? What about other applications?
The biggest issue for users that I have observed with not associating
"extra" data (like iPhoto categories) with the file data is that it
gets lost if the file gets moved or copied by any application other
than the one with the disassociated metadata. For applications like
iTunes this works as expected, as it places it's associated
attributes within the file data. But for applications like iPhoto
which keep a secondary database of associated metadata rather than
directly pairing it with the file data itself, copying the file
doesn't preserve any of this extra metadata.
Admittedly associating application metadata with file data raises the
question of how to deal with other issues like how to do proper
housekeeping, ownership and authority of attributes, eliminating
duplication, etc. But this is a secondary concern for most users
confronted by unexpected data loss.
Ultimately, trying to associate all of this goop with the file
itself represents a gross layering violation and something that's
downright perilous to do for all sorts of application / file
syncing reasons I won't go into here.
True, but it really depends on how this association is made. Sure
this goop may not belong as raw extended attributes, but it's
something that a lot of users expect the OS (not the application) to
just know how to handle. One thing worse than not being able to have
file metadata is not being able trust that it will be there if you
copy/move/backup the file.
What are you folks actually trying to do? Have you considered that
it might be the wrong thing? :)
Having spent some time trying to deal with syncing of file data,
metadata and filesystem data on tiger ( http://www.onthenet.com.au/~q/
rsync ) I have received plenty of emails from people confused by the
differences between what they expect to happen and how the system and
applications concerned actually work.
Pretty much all the confusion has revolved around application
metadata like Finder's .DS_Store or iPhoto's library catalogue, etc.
Spotlight only helps to further confuse things because it hides a lot
of what is actually going on under the skin. In a nutshell, what the
average Mac user expects is for a file's metadata (eg, comments,
tags, colours, groups, keywords, etc), regardless what application
it's related to, to be preserved when it gets moved/copied/backed up
no matter where it ends up. So that you can open it up at a later
date or on a different machine and expect to see that it and all it's
associated metadata is still intact. They don't want to have to worry
about secondary databases and the like, if they can see the file, and
drag & drop it, they want EVERYTHING about that file to go along with
it.
Which comes back to the issue highlighted in your previous statement.
Any application can have different ways of viewing or attributing a
given file. The problem with this kind of disassociated metadata is
that it's not actually associated with the file data at all, but
instead the filesystem's representation of the data as a filesystem
record (ie. the file or folder record). On top of that, each
application has to do it in its own way. So there is no way for a
system tool, (or 3rd party tool) to selectively copy files and their
associated application metadata. The only way is to use the
application in question to backup/export the files, which means you
can never have more than one application's attributions preserved
during the copy process.
If instead of maintaining their own disassociated databases,
applications were able to use some system provided framework to store
and retrieve application metadata for a file, similar to resource
forks, but stored by whatever means the OS chooses (spotlight,
appledouble files, extended attributes, whatever). This would go a
long way to being able to help solve this type of problem as it
places the operating system back in control of the data, and provides
a known, defined method for managing it when changes are made to the
associated file data. The upside of this is you get spotlight
searchability for free.
Sorry for the rant, I got a bit carried away.. but this has been
bugging me for a while.
--
Seeya...Q
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_____ / Quinton Dolan - email@hidden
__ __/ / / __/ / /
/ __ / _/ / / Gold Coast, QLD, Australia
__/ __/ __/ ____/ / - / Ph: +61 419 729 806
_______ /
_\
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden