Re: [Bug-tar] mtime in x header

[Michael D. Adams]

On Thu, Oct 1, 2009 at 3:46 AM, Sergey Poznyakoff <address@hidden> wrote:
> Hi Michael,
>
>>  (1) Is this behavior in conformance with the POSIX-2001 spec?
>
> As far as I can tell, yes, it is. POSIX says that the fields of
> a pax extended header block, other than its size, are not
> meaningful and should be selected such as to provide reasonable
> file access and times for the case when the archive is read by
> a tar utility not aware of pax extensions, in which case extended
> blocks will be extracted as regular files.

For 'x' headers, I would think the contained file's mtime would be
more "meaningful" than the tar file's creation time.  Though for 'g'
headers, I could see the tar file's modification time being more
"meaningful".  (I haven't tested 'g' headers.  I haven't figured out a
way to get tar to generate them.  (Which is fine, since my application
doesn't need them.))

(BTW, that probably means exthdr.mtime should also have an analogous
globexthdr.mtime option.)

>>  (2) Is there a way to work around this?
>
> Try the attached patch.  It introduces the exthdr.mtime argument
> to the --pax-option.  Its value is either a time in one of the
> formats described in [1] or a full path name to the reference file
> (just as with the --mtime option). For example, the following invocation
> should create binary equivalent archives:
>
> tar \
>  --pax-option=exthdr.name=%d/PaxHeaders/%f \
>  --pax-option=globexthdr.name=GlobalHead,exthdr.mtime='1 jan 1970',atime:=0 \
>  -c -f test.tar test.txt

Your patch works but has a bug.  If I set the time to '@1' or any
non-zero value it works, but if I set it to '@0' or '1970-1-1
00:00:00Z', then it reverts back to placing the tar file's creation
time in there.  (Note plain '1970-1-1 00:00:00' without the 'Z' is
local time and thus not zero.)

In xheader_write, I note that "exthdr_mtime_option.tv_sec" is being
checked to see if it is non-zero to determine if it has already been
set.  Of course when we use '@0', it will be zero so the function
assumes it hasn't been set.  Also I don't think C (at least prior to
C99) will always initialize exthdr_mtime to zero (compilers and OS may
vary).  (Then again maybe the tar sources are already assuming C99.)
The solution to all this is probably to have a variable next to
exthdr_mtime_option that signals whether it has been set and to
explicitly initialize that flag to false.

Otherwise, it seems to work great.

Michael D. Adams