tar problems

[pedz]

I have two machines. One has 10.4.2 server. My laptop has 10.4.2 client.

On the client, I can see tar able to cope with files with resource forks. If I put the v option during the create, I see it tar up /path/blah and /path/._blah if appropriate. (Sometimes it does it even if the rsrc fork is empty). Also, when I extract the files from the tar archive, things work as they should. The v option shows the resource forks being extracted and ls -l /path/blah/rsrc shows the resource fork in the new file just as before.

But on my server, life is not happy. I can pull over an archive created on the client and the server tar can untar it properly and things appear to be properly connected. But it can not create an archive. I’ve tried even as root.

I get errors like this:

tar: /tmp/tar.md.vBT4Uc: Cannot stat: No such file or directory
tar: /tmp/tar.md.j3l03v: Cannot stat: No such file or directory
tar: /tmp/tar.md.CNxS1Q: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors

The checksum on /usr/bin/tar is the same so it must be in some support library somewhere.

I’ve done a disk repair and repair permissions fairly recently.

Any ideas of how to fix this?

[Anonymous]

Use the command:
export COPY_EXTENDED_ATTRIBUTES_DISABLE = true

Before using tar, it seems that the problem is with the copyfile() function, which is part of the new 10.4 code that preserves forks.

See also: http://forums.macosxhints.com/printthread.php?t=43243

[Anonymous]

The problems seems to occur only when ACL’s are enabled. That’s why it happens on your server and not on your client. Disable ACL’s to fix the problem while still archiving your resource forks.

[Anonymous]

[QUOTE BY= Jelle Helsen] The problems seems to occur only when ACL’s are enabled. That’s why it happens on your server and not on your client. Disable ACL’s to fix the problem while still archiving your resource forks.[/QUOTE]

i guess that since acls aren’t really supported in that they’re not really well documented in tiger client, apple figured that they could get away with bugs like that. because i would have thought it would be pretty obvious that such a bug existed if anyone did any testing on a system with acls enabled … tarring stuff up is a pretty common task. anyway, it’s good to see that setting the env var will at least provide somewhat of a workaround. this fixes one of my issues where i don’t care about resource forks (custom build script in xcode) but doesn’t really help for my backup script, which had also been mysteriously failing with the same errors since i enabled acls to play around a bit with them.

hopefully someone at apple will read this, or someone has already filed a bug about it.

thanks for posting the info though, this was driving me crazy.

[pedz]

[QUOTE BY= Joel Franusic] Use the command:
export COPY_EXTENDED_ATTRIBUTES_DISABLE = true

Before using tar, it seems that the problem is with the copyfile() function, which is part of the new 10.4 code that preserves forks.

See also: http://forums.macosxhints.com/printthread.php?t=43243

[/QUOTE]

Encountered this problem again (10.4.4 client), found this thread (again), tried the export … as suggested and it worked for me.

Thank you to Joel (and the rest of AFP548)

[Author]

Posts