Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'beware of resource forks' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
beware of resource forks
Authored by: wallybear on Sep 30, '05 10:36:01AM

What about resource forks? Apple's zip will keep them, but this new one?



[ Reply to This | # ]
beware of resource forks
Authored by: danielj7 on Sep 30, '05 03:07:26PM

No, Apple has modified Tiger's command line programs--like zip, tar, cp, and rsync--to handle resource forks and other filesystem metadata. Any version you compile yourself or install with Fink or Darwinports won't have this support. You'd have to modify the source yourself to use Tiger's new *xattr family of functions.



[ Reply to This | # ]
beware of resource forks
Authored by: sjk on Sep 30, '05 03:45:04PM

The zip command on 10.4 doesn't preserve resources forks and extended attributes. "Create Archive of ..." in Finder does because BOMArchiveHelper uses the ditto command to create zip archives. That's my understanding anyway, which I can't double-check right now.



[ Reply to This | # ]
beware of resource forks
Authored by: silverdr on Oct 01, '05 03:17:31AM

It shouldn't matter much as long as one uses command line version only for unarchiving the passwd protected files, which by default don't come from a resource-fork enabled filesystem. But your remark does have a valid point of course.



[ Reply to This | # ]
beware of resource forks
Authored by: sjk on Oct 01, '05 11:16:50PM

Are you referring to kaih's comment? Your reply is threaded with wallybear's comment.



[ Reply to This | # ]
beware of resource forks
Authored by: vykor on Apr 26, '06 06:05:08PM

Apple's default command-line zip doesn't seem to retain resource forks as of 10.4.6. I ran into this just now, as two files sent to me, zipped via the command line zip utility, were without resource forks. Testing the command line version seemThe man page has a -df switch description, which seems to imply that resource forks would be kept unless -df is on. That line is misleading: even if you try to use -df, it appears have no effect at all on the compression behavior.

This is different from gzip and bzip2 in Tiger, both of which preserve metadata. And of course, ditto, which is probably the preferred way to generate resource-fork friendly archives, rather than zip.

The built-in zip has no encryption, apparently not resource fork aware, and the zipcloak utility is also a placebo only. If it weren't for system stability purposes, I would have just overwritten them with a newly compiled copy.



[ Reply to This | # ]