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.
_______________________________________________
Lzip-bug mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lzip-bug
