Re: [Bug-tar] Timestamps in ././@LongLink entries

[Sergey Poznyakoff]

Adam Greenblatt <address@hidden> wrote:

>     In tar-1.14, in create.c, the function "start_private_header" sets the
> mtime field of private blocks, such as "././@LongLink" entries, to be the
> current time.
[...]
> Here's a patch that will leave the mtime field of these private blocks
> set to all nulls, which seems harmless enough:

Thank you. However, the main purpose of this function is to provide a
uniform way of creating extended header pax archive format. Its use for
creating 'old GNU' private headers is secondary. According to pax
specification:

     [In extended headers], the size field shall be the size of the
     extended header records in octets. The other fields in the
     header block are not meaningful to this version of the pax
     utility. However, if this archive is read by a pax utility
     conforming to the ISO POSIX-2:1993 standard, the header block
     fields are used to create a regular file that contains the extended
     header records as data. Therefore, header block field values should
     be selected to provide reasonable file access to this regular file.

So, filling mtime with nulls in this case is not appropriate.

> This means that successive invokations of tar on an
> unchanging directory tree can produce different tar files;

Yes, this backward compatibility issue has been fixed on 2004-08-08.
The latest alpha alpha release (1.14.90) includes this fix.

Regards,
Sergey