Re: Copy Bundle Resources - a Question
Re: Copy Bundle Resources - a Question
- Subject: Re: Copy Bundle Resources - a Question
- From: Greg Guerin <email@hidden>
- Date: Sun, 28 Jun 2009 00:13:23 -0700
Steve Cronin wrote:
Why is it so hard to find the information?
I'm just guessing, but maybe it's because most people don't put
critical information in Finder comments. So not having programmatic
access isn't a big thing. Maybe this is a self-fulfilling prophecy
(i.e. the data is frequently lost or it's inaccessible, so most
people don't do it, so the lack of documentation doesn't affect many
people, and so on).
The Finder comments contain author; validator, and version
information.
The files are of varying types and produced by different tools.
Ultimately these data values determine deployment destinations.
Do you have a specific suggestion?
I did a little experimenting. This was on 10.4.11. (10.5 Leopard
does something completely different, see p.s. below.)
First, the Finder comments are not stored in extended attributes
(xattr's), at least not on 10.4. (Determined by listing a file's
xattrs using some code I wrote a while ago. Can also use the 'xattr'
command on Leopard: type 'xattr -h' for synopsis; no man page AFAICT.)
Second, the Finder comments are stored in .DS_Store on 10.4, but in
UTF-16 form, so the 'strings' command is unable to extract them.
(Determined by adding a distinctive comment to a file, then
opening .DS_Store in Hex Fiend.app.)
Third, archiving (compressing) a file then unarchiving it loses the
Finder comment on 10.4. I mention this mainly because it shows
Finder isn't entirely consistent in its handling of comments.
Fourth, the 'mdls' command shows the comment as the
kMDItemFinderComment item. So 'mdls' is able to read the comment,
but I don't see anything on 10.4 that can programmatically or command-
lineishly set a Finder comment.
Fifth, the 'cp' command preserves xattrs on a file, so if the Finder
comment is critical to you, you should consider extracting it with
'mdls' and writing it somewhere less volatile, such as a specific
named xattr. (The xattr system-calls can be listed using the
'apropos xattr' command, then read the appropriate man page.)
There may be another place to write persistent metadata, such as a
per-file version or author field that's stored in the resource fork
(wild guess, no evidence). Note: the normal copy files build phase
will strip resource forks, so plan accordingly. Programmatic or
command-line access to the resource fork? I doubt it, but I could be
wrong.
Also, depending on the file-type, there may be other standardized
ways to apply metadata to a file. Audio has ID3 tags, images have
EXIF, and there may be other standards for other types. I'm pretty
sure 'mdimport' will extract these and store them for 'mdls' to list,
so reading the metadata may be fairly easy.
Finally, it seems to me the Finder ought to be able to preserve
comments. Maybe look into using the 'osascript' command in a Shell
Script build phase, and simply 'tell app "Finder" ...' to copy the
files from their source to their destination location. I don't know
the AppleScript syntax for telling the Finder to copy files, but that
shouldn't be difficult to discover.
If the .DS_Store file is really the primary repository for Finder
comments, then I would not trust it to maintain any critical
metadata. Either preserve it in a more reliable form, or decrease
reliance on it.
-- GG
p.s. After writing all the above, I quickly tested 'xattr -l' on
Leopard, and it showed an xattr for Finder comment. The data is in
bplist format, but it should be copyable. In fact, 'cp' seems to
copy it, so maybe the above is completely wrong on 10.5 Leopard and
there's an entirely different reason that xattrs are stripped.
Another experiment for another day.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden