8

This question already has an answer here:

I have a tar that was generated on a linux machine. I need to upload part of that tar to another linux machine. The full tar is huge and will take hours to upload. I am now on a Mac OSX machine and this is my problem:

  1. I extract the tar to a folder and locate what I need to upload to the new server
  2. I create a smaller tar containing just what I want to upload.
  3. I upload and extract that to the new linux machine
  4. When I look the server it is full of ._ files. For every file uploaded there is a ._ file, like text1.txt, ._text1.txt, text2.txt, ._text2.txt...

OSX is including these files on the tar.

I have tried to do this

tar --exclude='._*' -cvf newTar  . 

without difference.

I do not have ssh access to the new server now.

What can I do to solve that? How do I generate a clean tar.

marked as duplicate by muru, Jeff Schaller, slm linux Jun 12 '18 at 0:59

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    Those files starting with "._*" are apple specific location indicator files according to THIS POST and you obviously can not get rid of them while logged in to your terminal om OSX, again according to the same page. You need to upload the file to a non-apple OS, get rid of those files and tar them up again. This seems to be the only solution. – MelBurslan May 9 '16 at 14:10
  • I was suspecting that. Thanks. Please convert your comment to an answer, so I can accept.\ – SpaceDog May 9 '16 at 14:12
  • 2
    @MelBurslan I don't see why, even if OSX recreates the files when they're deleted, that's no reason why tar can't exclude them. Are you suggesting that OSX's tar implementation automatically creates them in the archive? – terdon May 9 '16 at 14:12
  • 1
    @SpaceDog what happens if you run tar --exclude='text2*' -cvf newTar . ? Is text2.txt correctly excluded? Also, when running tar --exclude='._*' -cvf newTar . , do you see the ._ files listed in the command's output? – terdon May 9 '16 at 14:13
  • @terdon I am not sure but not all UNIX-like files on Aplle's OSX are the same as Their pure (as in non-apple) Unix counterparts. Apple does what apple thinks what is better for their users. I have never used OSX but heard few things not working as expected before for others on irrelevant topics. Hence I amnot writing my books on 100% compatibility between OSX and other UNIX flavors – MelBurslan May 9 '16 at 14:16
7

To my understanding, tar --exclude='._*' -cvf newTar . should work: Finder creates the ._* files but newTar shouldn't contain them.

But you can completely bypass those files by invoking tar in passthrough mode. For example, to copy only the files from oldTar that are under some/path, use

tar -cf newTar --include='some/path/*' @oldTar
17

The ._ files are how OS X bsdtar handles OS X-specific extended attributes and resource forks. (It's a mechanism known as AppleDouble, and it in fact applies to more than just TAR archives, being found in several storage formats where there is no native mechanism for holding MacOS resource forks and Finder information.)

To keep them from being added to your tar files, you can pass COPYFILE_DISABLE=1 as an environment variable to tar.

COPYFILE_DISABLE=1 tar cf newTar.tar /your/files

  • 4
    There is also an undocumented option --disable-copyfile. – fd0 May 10 '16 at 1:41
2

Those files starting with "._*" are apple specific location indicator files according to THIS POST and you obviously can not get rid of them while logged in to your terminal om OSX, again according to the same page. You need to upload the file to a non-apple OS, get rid of those files and tar them up again. This seems to be the only solution.

  • 4
    "you obviously can not get rid of them while logged in to your terminal om OSX" - this isn't obvious at all... they won't be gone permanently (which is what the site means by "If you manage to delete them, OS X will just remake them again"), but they will only come back when open that folder in the Finder again, so removing them while all windows are closed in the Finder and then making the tar file should work fine. – Random832 May 9 '16 at 14:19
  • my answer was based on the discussion topic from apple.com. Otherwise I have not worked on an OSX machine for any significant amount of time. Hence can not speak out of my ow experience – MelBurslan May 9 '16 at 14:23
  • I do confirm what @Random832 is saying. – Rui F Ribeiro May 9 '16 at 17:11
  • This is confusing the ".DS_Store" file (which stores things icon positions, and is a regular file that can be deleted on OS X) with "._" files. The "._" files are not actually part of the OS X filesystem; they're fake files used to store complex (/nonstandard) OS X file metadata when files are stored in a format that doesn't natively support OS X metadata. If you copy a file onto a FAT32 volume with OS X, it'll often be stored as two files -- the regular file, and a "._" twin with the original file's metadata. OS X uses the same trick in tar archives, .zips, etc. – Gordon Davisson May 10 '16 at 3:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.