bug-tar
[Top][All Lists]
Advanced

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

Re: [Bug-tar] [PATCH 1/2] tests: new test sparse04 for --sparse --posix


From: Kamil Dudka
Subject: Re: [Bug-tar] [PATCH 1/2] tests: new test sparse04 for --sparse --posix and long names
Date: Thu, 25 Nov 2010 10:40:07 +0100
User-agent: KMail/1.9.10

On Thursday 25 November 2010 09:55:09 Sergey Poznyakoff wrote:
> > attached are a regression test and sort of initial version of a fix
> > for https://bugzilla.redhat.com/656834 -- the problem is that during
> > xheader_decode(), the file name obtained from "GNU.sparse.name" is later
> > overriden by the dummy name stored in "path",
>
> It is intended, and in fact this is what the path keyword is for.
> According to the standard:
>
>   [path is the] pathname of the following file(s). This record shall
>   override the name and prefix fields in the following header
>   block(s).

Sergey, wait, what exactly is intended?  I suspect that malformed file
names of restored sparse files are not.  The name stored in "path" is 
(intentinally?) malformed by src/sparse.c during creation of an archive 
using "GNU PAX sparse file format 1.0".  The original file name is then 
stored in "GNU.sparse.name":

* 1.0

   Starting from this version, the exact sparse format version is specified
   explicitely in the header using the following variables:

   GNU.sparse.major     Major version
   GNU.sparse.minor     Minor version

   X header keeps the following variables:

   GNU.sparse.name      Real file name of the sparse file
   GNU.sparse.realsize  Real size of the stored file (corresponds to the old
                        GNU.sparse.size variable)

   The name field of the ustar header is constructed using the pattern
   "%d/GNUSparseFile.%p/%f".

Should I fix the archive creation then instead?

Kamil



reply via email to

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