using tar to Backup applications


I have been trying to use Tar to backup my applications and then burn them to CD for storage but it does not work. When i untar applications they lose their resource forks and change into folders and are nolonger applications. Does anyone have a solution.

PowerMac G4 450
ram 768
Mac OS X 10.1.5


...some random thought/ideas.

As far as I know, tar will work on Cocoa apps, but not on carbon ones - I could be way off base on that, however.
You might try using ditto instead, although that will do a copy, not an archive action.

The other thing to consider (although a little extreme, perhaps) is to use UFS instead of HFS+ for the filesystem. All files on the system will already be "split" into seperate files for data and resources (if the filename is "file" then the resource file will be "._file"), then you can tar them up (I think) without a problem.


Swollen Member
Originally posted by Stegion
Does anyone have a solution.
don't use tar :) stuffit is probably your best bet, and dropstuff is free. or you could make a compressed disk image if you have something against stuffit.


I like the idea of using a UFS filesystem. Here's one way that you could easily do this:
1) Use Disk Copy to make a UFS disk image
2) Copy your app to the disk image
3) Use tar to make a backup from the UFS image

I made a ufs disk image and could not copy anything to that image to TAR, it looks like i am stuck with stuffit

thanks for all or your help

PowerMac G4 450 mhz
ram 768
Mac OS X 10.1.5


The Mac Geekette!
I always find these conversations interesting but i usually dont know any of this techie talk. Could someone help me understand all this? It would be like really appreciated! Thanks![

Much Love,


The Mac Geekette /COLOR]


Try this article at O'Reilly's Mac Dev Center; it's a good primer on the various command line tools available on Mac OS X:

Utility / Preserves Permissions? / Preserves Resource Forks & Creator/Type?
cp / yes / no
CpMac/ no / yes
ditto/ yes / yes
rsync / yes / no

ditto will usually be your tool of choice, especially for preserving permissions and resource forks and other meta data. Due to its rich feature set and synchronization capabilities, rsync is a good choice for backing up portions of your /private/ directory tree. Personally, I use it to regularly back up /etc and /var/mail.


Puny Member
The fork isn't the only data tar fails to preserve. Creation date will also be lost as well as type/creator. Other things like icon position, Finder flags, etc. will also be lost.

The problem with tar and UNIX filesystems is they lack a generalized file fork/attribute API and so it will always be stuck int he past.

I don't suggest using UFS since it doesn't even support FileIDs. It's also very slow for some reason. Hopefully Apple or somebody else (Alsoft?) will develop a new filesystem, perhaps HFS++.


Originally posted by strobe
The fork isn't the only data tar fails to preserve. Creation date will also be lost as well as type/creator. Other things like icon position, Finder flags, etc. will also be lost.
does this mean the immutable flag is also lost !!


Puny Member
This isn't surprising given UNIX originally didn't have flags.

PS: I don't think the immutable flag is in the fork, I think it's one of the Finder flags. I could be wrong, but then I really don't care since the behavior of a locked file or folder has changed in OS X to something which is absolutely useless. In Mac OS it meant you couldmove the file but could not edit the contents. In OS X you can't move or renamt it, but you can move and rename a host directory which changes the path, which makes me wonder WTF UNIX egineers were thinking (but then I don't suppose they thin kin the first place).

Thus while the Mac OS locked flag was useful, the UNIX immutable flag is useless.


I think DropStuff, located on your HD and included with Mac OS X, preserves the resource forks of files. I knew that tar wouldn't work. I recently did a massive archive of programs and data to approximately 650MB file sizes to burn to CD. I didn't have enough free space to burn CDs, so I made the SIT files, FTP'd them to a PC at school, and started burning them one by one to CD, then I started transferring them back and deleting the ones already burned to CD. The archives worked. Life isn't fun when you end up with 200MB of free HD space (look at my specs below).


Puny Member
HFS+ has attributes of which finder flags are a part of. My primary machine doed so I don't have my bookmarks immediately handy but there is a technote on HFS Plus.

The fork stream doesn't contain any of this data. The resource fork only preserves resource fork data like a file's custom icon. It doesn't contain any file attribute data. This is no different than any other filesystem which contains no forks.

HFS+ supports multiple forks, but they have yet to be used. I don't even know if the OS uses them (either 9 or X). The problem with multiple forks is every app used to copy files has to support multiple forks, and since nobody uses them I doubt any do.

The key problem is thereis no general API for filesystems which weren't invented 30+ years ago. Or rather the problem is that we still use filesystems.


Puny Member
I MEANT to say I don't know if either OS supports them. I know for a fact they don't use them. In other words if you create a custom fork the Finder may not preserve it when copying files.

Anyway, screw filesystems. Nothing but a pain |-p


You should try using PsyncX. I find that it works better than any other application out there (okay, I'm biased. I wrote the thing, but still ... It works fine!)

Note: it is also free.