Re: [Lzip-bug] Tarlz 0.4: Scan or Simulate feature regarding 'ustar' format

[Antonio Diaz Diaz]

Hi Timothy,

Timothy Beryl Grahek wrote:
> When --scan or --simulate is called, it scans whatever folders or
> files are appended after --scan or --simulate and sees if those
> elements meet the requirements of the 'ustar' format.

You may achieve something like this with tarlz or with GNU tar:

$tarlz -c --uncompressed foo > /dev/null
tarlz: 
foo/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz: 
File name is too long.
tarlz: Exiting with failure status due to previous errors.

$tar -c --format=ustar foo > /dev/null
tar: 
foo/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz: 
file name is too long (cannot be split); not dumped
tar: Exiting with failure status due to previous errors

In fact GNU tar detects when the output is /dev/null and does not read 
the files:

http://www.gnu.org/software/tar/manual/html_node/file.html#SEC106
"When the archive is being created to `/dev/null', GNU tar tries to 
minimize input and output operations."


> since it [tarlz] by default uses 'ustar' for a very good reason.

I'm determined to find or modify a tar format suitable for tarlz. But it 
will take some time because I'll try to develop a consensus first with 
other tar developers and posix. It has been a shock to discover that pax 
is flawed. :-(


Best regards,
Antonio.