Eric Blake wrote:
It seems a bit ironic to add LZMA support but not offer tar-1.20.tar.lzma
on the ftp site :)
Just in case you are thinking about releasing a LZMA compressed tar
package, perhaps you would like to know there exists a much simplified
LZMA compressor/decompressor program and fo
Kevin Day wrote:
For the record, LZIP has a different binary header.
Instead of LZMA's "\xFFLZMA", it seems to only have: "LZIP"
There are two different file formats sharing the .lzma extension. The
header of one format begins with "\xFFLZMA\x00". The other format lacks
magic bytes in the hea
Hello.
The .tlz extension recognized by tar 1.20 conflicts with .tar.lz files
created by lzip. Perhaps you would prefer to solve this early, by using
.tlzma or something for .tar.lzma files, just in case tar supports lzip
in the future.
Regards,
Antonio.
Hello,
I was going to send a patch adding support for lzip files to tar but,
given that lzop and maybe other compression programs are already waiting
for such support and also that we are already scrapping the bottom of
the barrel regarding short option names, instead I propose to assign a
sh
Sergey Poznyakoff wrote:
Antonio Diaz Diaz <[EMAIL PROTECTED]> ha escrit:
I propose to assign a short name to the option --use-compress-program.
I agree. How about -I ? Mnemonics: visually similar to pipe symbol.
I like the idea more than you think, given that --use-compress-progra
Hello Sergey,
Sergey Poznyakoff wrote:
Do you plan to auto-compress/recognize lzip files (.lz)?
No problem. I'll only need some information on how to discern them
(e.g. by file header signature). Do you have any pointers?
I see tar-1.22.90 does not yet mention lzip files anywhere. In case
Tim Kientzle wrote:
A lzip file consists of a series of "members" (compressed data sets).
Each member has the following structure:
+--+--+--+--+++=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID string | VN | DS | Lzma stream | CRC32 | Data size | Member size |
+--+--+--
Karl Berry wrote:
Then Lasse Collin wrote lzma-utils which was the same compression
algorithm but was not an archive format
This is a very extended error. The author of lzma-utils is Ville
Koskinen, as you can see in lzma-4.32.7/src/lzma/lzmp.cpp:
" * Copyright (C) 2005 Ville Koskinen"
Lasse
Hello Sergey,
Antonio Diaz Diaz wrote:
Do you plan to auto-compress/recognize lzip files (.lz)?
No problem. I'll only need some information on how to discern them
(e.g. by file header signature). Do you have any pointers?
I see tar-1.22.90 does not yet mention lzip files anywhere. In
Kevin Day wrote:
There is the possibility of making up a new extension suffix for lzip.
I like too much the current scheme; gzip --> .gz || lzip --> .lz
However, on the other side of this argument, I do not think the
extension should matter. The purpose for identifying what a file is
or is
Kevin Day wrote:
The magic header is pretty easy:
modify buffer.c to have this:
{ ct_lzip, 4, "LZIP", "lzip", "--lzip" },
Sergey, I suppose you are busy, so I attach a patch with all the needed
changes.
Best regards,
Antonio.
diff -urdN tar-1.22.91/configure.ac tar-1.22.91.new/config
Hello Robert,
Robert Riemann wrote:
what about multithreaded compression with tar? Is anything related to
this already planned?
You can easily achieve this using "--use-compress-program=plzip".
http://www.nongnu.org/lzip/plzip.html
"Plzip is a massively parallel (multi-threaded), lossless dat
Hello Paul,
As a humble user of tar I thank you for writing this. I just found a
couple typos,
Paul Eggert wrote:
+extracting from an archive, ideally @command{tar} ideally encounters
Too ideally. :-)
+An tar-format archive contains a checksum that most likely will detect
"A tar-format
Paul Eggert wrote:
POSIX says that short reads are allowed only near end-of-file,
or when signals arrive, or for pipes, FIFOs, and special files.
They are not allowed while reading in the middle of a regular file,
Weren't GNU programs supposed to be free from such limitations[1]? For
example G
Marek Kielar wrote:
Please compare "colordiff" (http://colordiff.sourceforge.net/)
In Fedora, Debian and ArchLinux at least, it is in another package. Somebody
who needs it, finds it nevertheless - I'm a living example.
Interesting. I wish Internationalization could be implemented this way.
Sergey Poznyakoff wrote:
Interesting. I wish Internationalization could be implemented this way.
I'm not sure I understood what you meant. Tar is already
internationalized, isn't it?
I meant internationalization in general, not only for tar.
I find the way internationalization is currently
Paul Eggert wrote:
we are getting io errors.
Possibly that's because the tape is bad.
If this is the case and the cause are media errors, you can try reading
the tape with ddrescue[1].
[1] http://www.gnu.org/software/ddrescue/ddrescue.html
Regards,
Antonio.
peter.c...@stfc.ac.uk wrote:
# Rescue Logfile. Created by GNU ddrescue version 1.16
# Command line: ddrescue /dev/st0 /tmp/lto/tar logfile
# current_pos current_status
0x11E6E9E8000 /
# possize status
0x 0x0416D600 -
0x0416D600 0x007E4600 /
0x04951C00 0x0381BC00 -
Hello.
I have noticed that the short options '-I' and '-a' are not listed in
the node "3.4.3 Short Options Cross Reference" of the manual.
I attach a (trivial) patch.
Best regards,
Antonio.
diff -u tar.orig/tar.texi tar.new/tar.texi
--- tar.orig/tar.texi 2011-03-12 10:09:33.0 +0100
+
May I suggest that megabyte-sized text files be attached compressed:
$ ls -o config.log*
-rw-r--r-- 1 antonio 936144 2013-03-22 18:43 config.log
-rw-r--r-- 1 antonio 41109 2013-03-22 18:43 config.log.lz
It took me 5 minutes to download the message, and the mail program
locked to death trying
Paul Eggert wrote:
I think I'd rather have tar assume the gzip exit-status
convention, and depart from that only for bzip2 and lzip
(which don't use the convention). That's a bit simpler
and is more likely to match some random future compressor.
Only if the "random future compressor" continues
Pavel Raiskup wrote:
I agree that this would be the most logical. But there is a problem with
backward compatibility. The behaviour of --use-compress-program will
change.. what about this:
-I, --use-filter-program (general 'vanilla' API)
--use-compress-program (obsoleted alias to ^^^)
Pavel Raiskup wrote:
Use '--compres-program'-like API by the -Z, but also by -z, -J,
--lzop and --lzma options.
I oppose this, except perhaps for -Z.
AFAIK, tar files are compressible enough that none of those compressors
has been reported as returning 2, and if important programs like GNU ta
Paul Eggert wrote:
Converting gzip to the general API seems the right thing to do in the long term.
That might be wise, yes, but there might be other users who
expect the current behavior, and we'd need to consult with them.
To my surprise I have found that the current behavior is that gzip d
Pavel Raiskup wrote:
Hi Antonio, thanks for comments,
You are welcome. :-)
Exit value 2 is a general warning exit status among compressors
Then those compressors have a serious problem with their APIs that
should be fixed, or at least carefully documented. Callers like tar do
not mind if
Paul Eggert wrote:
If you look at the gzip source code you'll
find a number of circumstances that will
cause it to exit with status 2, as a warning.
Then gzip's API differs from compress's API[1] (return 2 only if size
increases and -f is not specified), and from "standard" API (only 0
means
Tim Kientzle wrote:
If you look at the source code for "compress", you find
that the return code 2 is *only* used when compressing
files in-place.
The source code for what compress? Mine is this (and it does return 2
when compressing stdin to stdout):
$ compress -V
Based on compress.c,v 4.0
Paul Eggert wrote:
If you look at the gzip source code you'll
find a number of circumstances that will
cause it to exit with status 2, as a warning.
It seems these warnings have been causing trouble since long ago:
http://www.gnu.org/software/tar/manual/html_node/Blocking-Factor.html#SEC157
"
Pavel Raiskup wrote:
Hi Antonio, some final comments from my site :). I don't want to beat
anyone.. and you are right, the code change would be a little bit larger
than my initial patch - and I can wait for complains that the change is
tooo big..
The problem is not (only) that the change is b
Pavel Raiskup wrote:
We could detect that archive contents are coming from terminal input and
fail immediately (IIRC tar waits indefinitely ATM until it's input is cut
by ctrl+d or it is killed).
I think this may be a good idea. It is a common feature among the
compressors used by tar:
$ l
Pavel Raiskup wrote:
I hope we came to conclusion that we really should not modify output (or
program behavior) based on what the output is (that goes against GNU
Coding Guidelines). We can only react on inputs (similarly like in my
[v3] patch). So in that regard I am against that patch.
As I
Jonathan Leffler wrote:
First of all, it creates a deep chain of directories with the name
'confdir-14B---' at each level. Then the creation process fails at a
rather deep nesting level. At this point, tools such as Bash have problems
processing the directory name. And, worse still, the direct
Charles Diza wrote:
FWIW, I hackily was able to remove the tree. There seems to be something
about the name "confdir-14B---", but I could be wrong about this. I wrote
a ruby script that descends the tree, renaming the Nth dir to "aN". After
this, I found that (a) the tree seems to stop at the
Hello Dmitri,
Dmitri Vorobiev wrote:
Attached are tarred up tests/testsuite.log as well as
tests/testsuite.dir.
Please, next time compress the logfile before attaching it. Think that
the GNU mail server must serve your file to all the subscriptors,
wasting a good amount of bandwidth.
$ ls
Joerg Schilling wrote:
POSIX requires st_blocks to be != 0 in case that the file contains data.
Please, could you provide a reference? I can't find such requirement at
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
Thanks.
Antonio.
Hello,
Both in the NEWS file and in the tar home page[1], the entries
corresponding to the addition of the --lzip option are missing. I attach
two (trivial) patches.
[1] http://www.gnu.org/software/tar/tar.html
Thanks,
Antonio.
--- NEWS~ 2017-01-29 20:17:07.0 +0100
+++ NEWS
I am pleased to announce the release of tarlz 0.3.
Tarlz is a small and simple implementation of the tar archiver. By
default tarlz creates, lists and extracts archives in the 'ustar' format
compressed with lzip on a per file basis. Tarlz can append files to the
end of such compressed archives
Jim Meyering wrote:
+m4_include([compress-gzip.at])
+dnl: omit lzma, because it would fail due to magic number mismatch
+m4_include([compress-lzip.at])
Given that Slackware has assigned the .tlz extension to lzipped
packages, should lzma_alone support be deprecated in GNU tar?
Best regards,
Please, compress the logs. It saves 96% of bandwidth:
-rw-r--r-- 1 982019 2019-01-04 01:23 testsuite.log
-rw-r--r-- 1 39912 2019-01-04 01:23 testsuite.log.lz
Thanks,
Antonio.
Hello,
KO Myung-Hun wrote:
OS/2 is still being maintained and developed as
eComStation(https://www.ecomstation.com) and now
ArcaOS(https://www.arcanoae.com).
"Arca Noae brings OS/2 into the 21st Century".
I think it would be better if OS/2 could be brought into the 21st
Century by removing t
Hello.
In the tar manual we can read:
http://www.gnu.org/software/tar/manual/html_node/Old-Options.html
"As far as we know, all tar programs, GNU and non-GNU, support old options".
FWIW, there is at least one non-GNU tar program which does not (and does not
plan to) support old options.
[1]
Paul Eggert wrote:
This discussion suggests the need for a new, easy-to use format option,
which is like '-Hpax' except that it omits atime and ctime, and omits
the subseconds part of mtime. Using this format would mean that pax
extensions won't be used unless they're needed (a file with a long n
Mike Frysinger wrote:
i like it for automake, and to help pull more of the ecosystem up to pax.
I don't think "pulling more of the ecosystem up to pax" is such a good idea.
Pax is not a good format neither from the point of view of efficiency nor
from the point of view of safety. IMO pax exte
Helge Kreutzmann wrote:
Man page: tar.1
Issue:archive --> archive itself
"%s: file is the archive; not dumped"
FWIW, as a non-native English reader but somewhat experienced tar user, I
prefer the current message to the change proposed. I think it is already
clear what "the archive" means
Paul Eggert wrote:
Perhaps a rewrite of the diagnostic instead? Something like this?
$ tar -cf foo.tar a b c foo.tar d e f g
tar: foo.tar: archive cannot contain itself; not dumped
Excellent idea! This makes explicit the cause of the problem.
Hello.
I have found a typo in the manual in section 3.4.2 "tar Options", in the
last line of the description of '--full-time'[1]:
"Notice, thar when creating the archive you need to specify '--verbose'
twice to get a detailed output"
s/thar/that/
I also think that the comma after "Notice"
Thanks Paul.
Paul Eggert wrote:
+@node Reproducibility
+@section Making @command{tar} Archives More Reproducible
+
+Sometimes it is important for an archive to be reproducible,
+so that one can be easily verify it to have been derived solely from its input.
I think that in the last line above
Hello Klaus,
Klaus Kusche wrote:
* Compare how `star` performs; it uses a very different buffering
architecture which may uncover other possibilities.
My distribution no longer packages star.
Perhaps you may try some experiments with 'tarlz -c --no-solid', which opens
and reads the files
48 matches
Mail list logo
