1

I am trying to create backups on an external exFAT disk, but I keep getting errors. I have to use FAT (exFAT or FAT32), so my options are very limited. I will need this to backup both macOS and Windows.

My first go-to solution was using tar with split (1gb file size) on macOS, but I keep getting errors when checking the validity of the backup:

% cat Personnel.* | tar tvf -
drwxr-xr-x  0 ab     staff       0 Feb 24 10:58 Personnel/
drwxr-xr-x  0 ab     staff       0 Dec  1 14:02 Personnel/Settings/
-rw-r--r--  0 ab     staff   14340 Feb 24 10:58 Personnel/.DS_Store
drwxr-xr-x  0 ab     staff       0 Jul 26  2021 Personnel/Forms/
tar: Special header too large
tar: Error exit delayed from previous errors.

The command line is with a pipe (tar cvf - Personnel/ | split -b 1024m - Personnel.).

I have checked the drive with Disk Utility, but no errors show up.

Sincerely, I have no clue, and google didn't help that much.

Any possible hints?

Improve this question
3
  • Why are you splitting the files at all? You said you have to use "exFAT or FAT32" – one of those has a 4GB file size limit, the other does not.
    – grawity_u1686
    Commented Feb 24, 2022 at 15:52
  • @user1686 all files will be uploaded to a cloud storage server, easier with unruly connections than using one big archive.
    – senseiwa
    Commented Feb 24, 2022 at 17:39
  • It has been a while since I used tar, but it seems like the method that you are using would put the contents of all those files into a single file which is then tar’ed and split. Why use cat at all? Just include the full files themselves, not the file contents, in the tar. Or, better yet, just use rsync and keep all of the files as files, and not inside a tar.
    – jimtut
    Commented Feb 24, 2022 at 20:57

1 Answer 1

Reset to default
1

The error means that a tar header entry is too long ( see tar.c).

This means that the cat command created a bad archive.

It seems that cat Personnel.* perhaps included some wrong file.

Improve this answer
7
  • Thanks for the pointer, but I have just now used cat with all the file names one by one in order, and I get the same error...
    – senseiwa
    Commented Feb 24, 2022 at 17:49
  • Somehow, the result of the cat is incorrect. Try to cat all to one file if you wish to check. I hope that macOS doesn't have a problem with exFAT.
    – harrymc
    Commented Feb 24, 2022 at 19:17
  • No, it is not a problem with FAT/exFAT. It turns out, some directories had custom icons made with macOS via Finder (copy/paste icons when "Get Info" window is open). Well, those are hard links and tar breaks down with that error. I don't know how to update the question now, or even if this can be filed as a bug. Certainly, nowhere Finder told that icons were hard links...
    – senseiwa
    Commented Feb 25, 2022 at 13:46
  • Right, so it was the tar cvf that destroyed the archive, so that the archive in Personnel.* files truly contained incorrect header entries.
    – harrymc
    Commented Feb 25, 2022 at 14:15
  • 1
    I am seeing exactly this behavior when creating a ~100MB tar file on an APFS volume. I'll try to track down what's triggering it.
    – Dylan McNamee
    Commented Mar 19, 2022 at 21:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .