• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Metadata support
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Metadata support


  • Subject: Re: Metadata support
  • From: Boyd Waters <email@hidden>
  • Date: Sun, 25 Jun 2006 21:33:39 -0600


On Jun 25, 2006, at 7:02 PM, Jordan K. Hubbard wrote:

What are you folks actually trying to do? Have you considered that it might be the wrong thing? :)

Oh, I consider that I'm doing the wrong thing about six times before breakfast... :)


I'm trying to back up my files from Mac OSX to Linux or FreeBSD, and I want the extended attributes to be mapped to the foreign file system so that a file's attributes may travel reliably from copy to copy on the Linux side (e.g., across server backups) and still make sense when the file is examined by a Mac.

If I understand correctly, then Spotlight simply derives search features from the underlying data: re-generating these features is the way to go. (I'm not asking for Spotlight to shove all of an MP3 song file's information attributes into the file's POSIX xattrs.)

But Finder attributes, to name another application, are _not_ derived from the underlying data: where it a file's Finder label stored? In some other file. Surprise, surprise...

I am anticipating an "extended Finder" that will expose extended attributes to the GUI, allowing users to tag files and create more effective smart folders. The fact that the system may cache these attributes in a SQLite store or some hash is immaterial, an implementation choice. What I _don't_ want is for there to be some orthogonal store for these per-file attributes.

I want per-file attributes to be maintained with the file - semantically "in" the file.

- so that cp, tar and friends properly maintains these attributes. I think that mapping these attributes to POSIX xattrs is a no- brainer, particularly if the attribute names follow the reverse-DNS attribute namespace that Spotlight made us think about.

It may be that Apple's prior implementation of resource forks has soured OSX filesystem people on this notion. But there seems to be a standard for (at least) simple name-value pairs now. Why not use it?


(Thanks for the comments!)

 - boyd

Boyd Waters
National Radio Astronomy Observatory
Socorro, New Mexico

Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
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

  • Follow-Ups:
    • Re: Metadata support
      • From: "Jordan K. Hubbard" <email@hidden>
References: 
 >Metadata support (From: Tomas Zahradnicky <email@hidden>)
 >Re: Metadata support (From: Q <email@hidden>)
 >Re: Metadata support (From: Dan Shoop <email@hidden>)
 >Re: Metadata support (From: Boyd Waters <email@hidden>)
 >Re: Metadata support (From: "Jordan K. Hubbard" <email@hidden>)

  • Prev by Date: Re: Metadata support
  • Next by Date: Re: Metadata support
  • Previous by thread: Re: Metadata support
  • Next by thread: Re: Metadata support
  • Index(es):
    • Date
    • Thread