[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-tar] 1.15.91 file name too long to be stored in a GNU multivolu

From: mark jackson
Subject: Re: [Bug-tar] 1.15.91 file name too long to be stored in a GNU multivolume header, truncated
Date: Tue, 01 Aug 2006 21:50:58 +0200
User-agent: Thunderbird (Windows/20060516)

Sergey Poznyakoff schrieb:
> mark jackson <address@hidden> wrote:
>> the interesting thing comes now when i compare the original-directories
>> and the new created directories with
>> "diff -r <original-directory> <new created directory>"
>> there is NO difference; so it seems that the backup worked perfect;
>> so why are these errormessages?
> These are not error messages, only warnings.
> When creating multivolume backups it often happens that a file
> needs to be split between two volumes. In this case GNU tar
> stores the file name along with some additional data at the
> beginning of the next volume in a special block called volume
> header. In GNU format this header can accomodate file names 
> up to 100 characters long; if the actual name is longer than
> that, tar truncates it and stores only the first 100 characters
> in the header. This is what
> "file name too long to be stored in a GNU multivolume header, truncated"
> diagnostics means.
> When restoring from a multivolume backup, tar uses volume headers
> to verify that the user is feeding archive volumes in the right order. This
> is achieved by comparing the file name and starting byte offset stored
> in the next volume with the name and offset of the file being extracted.
> If tar notices that the next volume contains a truncated name and the
> offset of that volume matches, it continues extracting the file but
> issues the warning
> tar: `foo' is possibly continued on this volume: header contains truncated 
> name
> The purpose of this warning is to draw user's attention to the fact that
> tar is not 100% sure this is the right volume, since it was only able to
> compare first 100 bytes of the file name and the byte offsets.
> Regards,
> Sergey

thanks for this very good explanation;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]