tar files corrupting applications

mromey

Registered
In the process of finding a usable method of transferring files from machine to machine I started to use the tar command in the terminal. Unfortuantely I have been having some problems with certain applications. For example I have been trying to make a tar file of the application directory.

tar -cvf Applications.tar /Applications

It seems to work for the most part excep for a few applications. After I tar the Adobe Acrobar Reader and untar the file, it is corrupted. I have been using the following command to decompress:

tar -xvf Applications.tar

this issue happens with other applications as well when they are tared, but they don't appear to happen with Apple compiled software. Are the software companies not doing something that apple is. Does anyone have any ideas.

ROMAN
 
Originally posted by mromey
tar -cvf Applications.tar /Applications

It seems to work for the most part excep for a few applications. After I tar the Adobe Acrobar Reader and untar the file, it is corrupted. I have been using the following command to decompress:

tar -xvf Applications.tar

The tar command is ignorant of the dual-fork property of some Macintosh files, of which Reader is probably one. The resource fork does not get included in the tar transfer.

Go to versiontracker and get the latest hfspax, a tar clone that understands resource forks.
 
You know, I just got in the office to check my email this morning. I haven't been gziping my files, but this makes no difference. It appears as though I'm having a similar problem with the copy command. If you cp -r Acrobat\ Reader\ 5.0 it is also corrupted. Does the cp command have problems copying data forks as well?

Later toady I'm going to try to download the new tar app. Maybe this will make my life a bit lass painful.

Roman
 
Originally posted by mromey
[...] It appears as though I'm having a similar problem with the copy command. If you cp -r Acrobat\ Reader\ 5.0 it is also corrupted. Does the cp command have problems copying data forks as well?

None of the 'old' Unix commands handle resource forks. Not tar, not cp, not cpio, not dd. Even ls -l only displays the size of the data fork, though ls -l (filename)/rsrc will show the size of the resource fork.

If you install the Developer Tools, you will get some Apple commands like CpMac that copy the whole file, including resource fork.

Only HFS[+] file systems support resource forks on the Mac. If you mount a DOS/Windows file system using the Samba client, rules are different.
 
Did you try tarring the archive, then gzipping or bzipping it, I'm pretty sure that it should work if you just tar a whole directory because that shuold compress everything else inside of it. If you are having errors maybe it is because of some preferences too?

Justin
 
Yes, I tryed to move the files/applications into a directory then tryed taring the new directory. No juice.

A quick thought, is it possible that Alladdin's DropTar includes the resource fork? What is weird is that the move tool works perefectly but when I try to cp a file like /Applications/Acrobat\ Reader\ 5.0.app it still doesn't copy the resource fork.

I did download the hfspax application and it did work. It just seems like this is an important oversight on the behalf of Apple. If your going to adopt an older OS like UNIX and add your own twist and flair to the OS you should adapt the applications to the new flavor of the old OS. Regardless of HFS or HFS+, or what ever. Very frustrating.

I wanted to thank everyone for all the very usefull information.

Roman
 
You're better off using Stuffit or the afore mentioned tar that understands resource forks. If you don't have Stuffit, a cheap, but convoluted, hack would be:

1. Use DiskCopy to create a .dmg image the size of the files you want to copy.
2. Mount the image
3. Copy the files
4. Unmount the image
5. Open a terminal window
6. cd to the directory containing the .dmg image
7. type: tar -czf somename.tgz imageyoucreated.dmg

You can then copy the compressed file wherever you want.

In this case tar isn't really neccessary. You can just type gzip somename.gz imageyoucreated.dmg. Tar is only usefull for multiple files
 
Originally posted by mromey
What is weird is that the move tool works perefectly but when I try to cp a file like /Applications/Acrobat\ Reader\ 5.0.app it still doesn't copy the resource fork.

Not weird at all. If you're moving a file on the same harddrive and partition (volume) then "mv file.name /some/place" doesn't move the file, but instead just changes the pointer in the file system (i.e. in the directory of files is just says "file X is now there, not here") Hence, the file is never touched and the resource forks remain the same. The same thing happens in the finder. When you drag a file from one folder to another on the same volume, it's almost instantly moved. When you drag it to another volume, the whole copy dialogue comes up.

Copying a file creates a whole new file. And since cp doesn't understand resource forks . . .

Yoiu'd notice the same problem as cp if you used mv to move to a new volume, because in that case mv actually creates a new copy, then deletes the old copy.
 
Can't take any credit at all for this, because I'm just repeating something a much wiser and more experienced *NIX user mentioned, but -
There is a copying command that preserves resource forks:
ditto -rsrc [file to copy] [destination]
It has worked perfectly for me (so far).
:D
 
Okay so this 'ditto' command is very cool. I take it that this command is somewhat MAC OSX specific because it wasn't located on our IRIX machine. Anyhow, so now I'm happy. why use 'cp' over 'ditto'. I'm thinking of mapping the 'ditto' command to 'cp' in my .aliasrc file. Is this a good idea, or is it bad news? Does apple provide another application like 'ditto' that works for 'tar' files? Tar, being an application that uses the functionality of 'cp', is it possible to replace the functionailty of copying file with ditto.

Roman
 
Back
Top