[SOLVED] file name too long to be stored in a GNU multivolume header

Thymox · 09-03-2009, 04:13 AM

Hi all,

A quick script to backup one of our servers - it uses tar and splits the tar file into multiple files of a known size. Unfortunately, it would seem that tar (when using the GNU format) doesn't support long file/directory paths in a multi-volume header.

The heart of the script is noted below:

Code:

  tar \
    --files-from=$strINCLUDE \
    --exclude-from=$strEXCLUDE \
    --recursion \
    --create \
    --file $strBACKUPLOCATION/backup \
    --multi-volume \
    --tape-length $strSIZE \
    --format=gnu \
    --new-volume-script $strBACKUPLOCATION/post_tar_script.sh

Where am I going wrong? If I set --format=pax then it fails completely complaining of incompatible features.

Grant.

colucix · 09-04-2009, 03:55 AM

Odd! From the GNU tar manual:

Quote:

Archives in ‘gnu’ format are able to hold file names of unlimited length.

regardless of being a multi- or single volume. Please, can you post the exact message you get? I suspect the massage comes from the post-processing script (post_tar_script.sh) instead.

Thymox · 09-05-2009, 04:49 PM

The title of the thread is the exact error message.

The job is run at 1am by a cron entry. The cron entry does not redirect stdout nor stderr to /dev/null (purposefully, so we get mailed the results). The mail is as follows:

Code:

tar: Removing leading `/' from member names
tar: /var/run/dbus/system_bus_socket: socket ignored
tar: /var/run/acpid.socket: socket ignored
tar: /var/run/fpcgisock: socket ignored
tar: Removing leading `/' from hard link targets
tar: var/qmail/mailnames/blahblahblah: file name too long to be stored in a GNU multivolume header
tar: Error is not recoverable: exiting now

The post_tar script is as follows:

Code:

#!/bin/sh
strBACKUPLOCATION=/var/backups

. $strBACKUPLOCATION/variables

echo $strNEWCOUNT > $strBACKUPLOCATION/count
# Renames the "backup" file to "backup.date.count"
mv $strBACKUPLOCATION/backup $strBACKUPLOCATION/$strFILENAME

# BZip2 file, consequently renaming as backup.date.count.bz1
#bzip2 --compress --fast $strBACKUPLOCATION/$strFILENAME
#strFILENAME=$strFILENAME&".bz2"

# Find size of file and add it to textfile
strSIZEOFFILE=`ls -l $strBACKUPLOCATION/$strFILENAME | awk '{print $5}'`
echo $strSIZEOFFILE $strFILENAME >> $strBACKUPLOCATION/filesizes.list
echo . >> $strBACKUPLOCATION/filesizes.list

lftp -c "open $strHOST -e 'put $strFILENAME -o $strDAY/$strFILENAME' -u $strUSER,$strPASSWD"

# FTP the file to FTP server
#ftp -n $strHOST <<END_SCRIPT
#quote USER $strUSER
#quote PASS $strPASSWD
#quote put $strFILENAME $strDAY/$strFILENAME
#quit
#END_SCRIPT

# Move file to "ftped" folder.
rm -f $strBACKUPLOCATION/$strFILENAME

Not exactly a clean bit of code, but it works.

colucix · 09-06-2009, 01:23 AM

I glanced through the tar source code and found this, as a comment inside the block of code that writes the multi-volume header:

Code:

/* FIXME: Michael P Urban writes: [a long name file] is being written
   when a new volume rolls around [...]  Looks like the wrong value is
   being preserved in real_s_name, though.  */

As you can see, it looks like an open bug. The comment above comes from the latest sources, version 1.22. I'd give the latest release a chance, anyway.

Thymox · 09-07-2009, 03:48 AM

Ouchy! We're still on tar v.1.15.1. FC4 server that's badly in need of updating but we can't really afford to take various services off-line.

Thank you.

swilsy · 11-11-2017, 02:00 PM

I did not want to duplicate this thread, so I am posting here. I am running into the same issue. I am trying create multiple 1TB .tar files as part of a backup routine using the -M option with the tar utility.

My tar command looks like this:

Code:

tar -cM --file=Backup_A.tar --file=Backup_B.tar --file=Backup_C.tar --file=Backup_D.tar --file=Backup_E.tar --file=Backup_F.tar --file=Backup_G.tar --file=Backup_H.tar --tape-length=1T /DirToBackup

When tar got to the end of the first 1TB .tar file, it through out a message that said

Code:

:file name too long to be stored in a gnu multi volume header, truncated

after the name of file with a really long path. Based on some quick research, this seems to only be an issue when a file with a long path is straddling two archive files. This looks like the same bug referenced in this original post. Is there any work around or solution for this issue?

Tar version is 1.28. Running Ubuntu Server 16.04.