Paul Eggert wrote:
> As I vaguely recall, this extension was designed by both of us in
> collaboration, and superseded an earlier base-256 format that GNU tar
> still supports but does not document. I'm too lazy to consult the email
> archives to check my memory; it's not a big deal either way
On 11/20/2017 02:51 AM, Joerg Schilling wrote:
That's a shortcoming in tar's documentation. Tar uses the GNU format by default,
which has a base-256 extension that supports negative timestamps. If you want
GNU tar to refuse to use this GNU extension, please use '-H ustar'.
Well, base-256 is not
Paul Eggert wrote:
> Rodrigo Queiro wrote:
>
> > I discovered this because Python's tarfile module fails to open such files
> > with "invalid header", since it expects this field to contain an ASCII
> > number, as described in the docs:
>
> That's a shortcoming in tar's documentation. Tar uses th
Thank you! FYI, there's a typo in 0003 - "concatenating" instead of
"concatenated".
On Sat, Nov 18, 2017 at 5:48 PM, Paul Eggert wrote:
> Rodrigo Queiro wrote:
>
> I discovered this because Python's tarfile module fails to open such files
>> with "invalid header", since it expects this field to
Rodrigo Queiro wrote:
I discovered this because Python's tarfile module fails to open such files
with "invalid header", since it expects this field to contain an ASCII
number, as described in the docs:
That's a shortcoming in tar's documentation. Tar uses the GNU format by default,
which has
