On Thu, Oct 1, 2009 at 3:46 AM, Sergey Poznyakoff <[email protected]> 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
