MACSCRPT Archives

May 2008

MACSCRPT@LISTSERV.DARTMOUTH.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Ivan Drucker <[log in to unmask]>
Reply To:
Macintosh Scripting Systems <[log in to unmask]>
Date:
Thu, 15 May 2008 01:51:04 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (90 lines)
Well, if you extracted the tar file on a PC, you'd get similar results as
with a Mac-created zip file, except that ._MyForkedFile (finder
info+resource fork) would appear alongside MyForkedFile (data fork), rather
than in a __MAC OS X folder. (._MyForkedFile might also actually appear as
invisible; I haven't tried.)

Also, Windows has no native understanding of TAR, and AFAIK neither does
WinZip, so you'd need StuffIt Expander or some other utility to deal with
it. I'd probably distribute .tgz files only to Mac or Unix users for that
reason.

Good question about cpio; I have no experience with it.

Ivan.

On 5/10/08 10:03 AM, "Mark J. Reed" <[log in to unmask]> wrote:

> Good to know that tar(1) handles resource forks and Finder metadata,
> too. How portable are such archives? If I take a zip file with the
> extra info and extract it on a pc, I just get extra files.  Is that
> true of the tar archives as well?
> 
> And just to complete the trifecta, what about cpio(1)?  That appears
> to be the default archive format used by ditto(1).
> 
> 
> 
> On 5/10/08, Ivan Drucker <[log in to unmask]> wrote:
>> Short answer: use gzipped tar instead of zip; it honors resource forks, and
>> can be expanded by double-clicking in the Finder in the same way zips can.
>> Syntax:
>> 
>> archive: tar zcvf MyTarFile.tgz MyFile1 [MyFile2 MyFile3 etc...]
>> extract: tar zxvf MyTarFile.tgz
>> 
>> (Omit the v's if you don't want it display what files it has processed.)
>> 
>> Long answer:
>> 
>> The Finder handles archives via /System/Library/CoreServices/Archive
>> Utility.app (BOMArchiveHelper.app prior to Leopard). When you choose
>> "Compress..." (or "Create Archive" in Tiger), it creates the following
>> inside your zip file:
>> 
>> MyForkedFile
>> __MAC OS X/._MyForkedFile
>> 
>> The first file is the data fork, and the second contains both Finder
>> metadata and the resource fork (in that order). When you double-click a .zip
>> file made this way, Archive Utility knows to glue them back together and
>> provide you with a single forked file.
>> 
>> Unfortunately, the zip command line tool doesn't honor this structure, and
>> if you unzip an archive created via the Finder, the above is exactly what
>> you'll get, rather than a single forked file.
>> 
>> In 10.5.2, the zip man page is definitely out of sync with the program; it
>> looks as though they had plans on making it more fork-friendly, but that's
>> not what shipped. Neither the Mac-specific -df or -S options actually work
>> when invoked.
>> 
>> If you want to actually access or separate the data and resource forks, you
>> can access the resource fork from the command line with this syntax:
>> 
>> MyForkedFile/..namedfork/rsrc
>> (This can also be abbreviated to MyForkedFile/rsrc, though this form has
>> been deprecated, meaning it may stop working in some future version of Mac
>> OS X.)
>> 
>> I tried using this technique to see if I could make an AS routine that would
>> make .zip files that are compatible with the ones created by Archive
>> Utility, but the problem is I also need the Finder header information so it
>> knows what kind of file it is, and then I remembered that tar will do all of
>> this already.
>> 
>> Best,
>> Ivan.
>> 
>> 
>> 
>> On 5/8/08 7:47 AM, "Mark J. Reed" <[log in to unmask]> wrote:
>> 
>>> When I compress files via the Finder, I get a .zip file that includes
>>> the resource forks.  When I use zip from the shell, no such luck. I've
>>> checked the man page and it mentions an option to exclude the resource
>>> fork, but it seems to be doing that by default, and I don't see the
>>> inverse option.  So how can I get a zip file inclusive of resource
>>> forks from the shell?
>> 

ATOM RSS1 RSS2