On Tuesday 30 October 2007, Amarnath Sharma wrote:
> form where I can find GNU tar binary for redhat linux.
> My RH-Linux has GNU tar version 1.14 and I want to upgrade.
you can either ask the redhat people or you can compile it yourself from
source. rarely do upstream maintainers (the GNU tar p
On Tuesday 11 December 2007, fedusr wrote:
> Why is 'tar --create --verbose' output not sent to ? There could
> be a default value switching to in '--create'
> operations, and '--list' keeps operating in stream mode.
>
> But it remains a little bit strange resp. a dilemma. The 'GNU Coreutils
> M
On Tuesday 11 December 2007, Radek Brich wrote:
> On Tue 11. of December 2007 09:44:18 Mike Frysinger wrote:
> > On Tuesday 11 December 2007, fedusr wrote:
> > > Why is 'tar --create --verbose' output not sent to ? There
> > > could be a default value switchin
just debating whether to back port the lzma updates to tar-1.19 or just wait
for tar-1.20. if the answer is "nfc", that's fine :).
-mike
signature.asc
Description: This is a digitally signed message part.
On Thursday 10 April 2008, Vitaly V. Ch wrote:
> On Thu, Apr 10, 2008 at 5:05 AM, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > just debating whether to back port the lzma updates to tar-1.19 or just
> > wait for tar-1.20. if the answer is "nfc", that's f
On Tuesday 28 October 2008, Tristan Miller wrote:
> GNU tar 1.20 seems to have no trouble creating lzma-compressed files when
> specifying the -a option and a filename ending in .tlz or .tar.lzma.
> However, it doesn't recognize these extensions when extracting (with or
> without the -a option).
t
recently (2008-11-25), this change was committed:
2008-11-25 Sergey Poznyakoff
Do not try to drain the input pipe before closing the
archive.
* src/buffer.c (close_archive): Remove call to
sys_drain_input_pipe. Pass hit_eof as the second
argument to sys_w
On Monday 29 December 2008 05:48:54 Sergey Poznyakoff wrote:
> Hi Mike,
> > you may say "well just check the exit status of tar and go with that",
> > but that doesnt work for cases where the decompressor
> > crashes/exits/whatever early on and tar gets a short archive.
>
> For the best of my knowl
On Monday 29 December 2008 06:25:58 Sergey Poznyakoff wrote:
> Mike Frysinger ha escrit:
> > i dont have a full list of issues available as they've been lost to
> > time,
>
> Oh, that's a pity. If you find any, please let me know.
my (limited) understanding of
On Monday 29 December 2008 06:40:24 Sergey Poznyakoff wrote:
> Mike Frysinger ha escrit:
> > it is entirely possible for the compressor to exit abnormally at
> > locations in the stream such that tar simply thinks there is nothing
> > left
>
> Yes, that's true
On Thursday 05 March 2009 13:29:55 Sergey Poznyakoff wrote:
> Sebastian Pipping ha escrit:
> > Do I understand correctly, that the .lzma and .xz file formats ares
> > not compatible?
>
> If I'm not mistaken, they are backward compatible.
well, backwards compatible in the sense that the newer xz-u
On Monday 13 April 2009 16:24:48 Martin Koeppe wrote:
> On Mon, 13 Apr 2009, Kamil Dudka wrote:
> > On Sunday 12 of April 2009 12:26:29 Martin Koeppe wrote:
> >> I have now narrowed down this issue. The best example now is the
> >> Debian source for GNU tar. While I could successfully extract
> >>
On Tuesday 28 April 2009 08:25:28 Jörg Walla wrote:
> the MAN Page of tar has an Bug on the position:
>
> --no-recurse
>keine Verzeichnisse sichern
>
>
> "-recurse" doesn't work, "-recursion" works
the gnu tar project doesnt include a man page (unfortunately). this bug is
specific
On Wednesday 02 December 2009 13:40:33 Mike Maki wrote:
> I've been looking at how to do this, but haven't found out how to make a
> tar.exe that will run in a dos cmd shell. Do I need to compile on a
> non-cygwin system using non-gnu compiler? The last thing I want to do is
> use MS VCC. I'm requi
On Thursday 17 December 2009 00:27:21 Linda A. Walsh wrote:
> Notably, the Gnu file command doesn't recognize lzma archives as archives
> -- it just thinks they are 'data' (file V 4.24). Could this be related?
> Note - if you specify the --lzma switch, it compresses fine, so nothing
> wrong w/
On Friday 13 January 2012 10:36:31 Mark Krenz wrote:
> However there isn't really anything in the man page
unfortunately, the GNU tar project has yet to ship a man page (i've tried to
get one merged). so you'll have to report this bug to the distro you're using
since it is the distro's that are
automake spits out warnings as the latter is deprecated.
Signed-off-by: Mike Frysinger
---
paxlib/Makefile.am | 2 +-
paxtest/Makefile.am | 2 +-
rmt/Makefile.am | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/paxlib/Makefile.am b/paxlib/Makefile.am
index 3e31857
Editors and autotools generate these type of files as automatic backups.
Signed-off-by: Mike Frysinger
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 04e4f34..a353d05 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,6 +2,7 @@
*.la
*.lo
*.o
Since rmt depends on these two modules, add them to the list.
Signed-off-by: Mike Frysinger
---
paxlib.modules | 2 ++
1 file changed, 2 insertions(+)
diff --git a/paxlib.modules b/paxlib.modules
index 5efe05b..5627911 100644
--- a/paxlib.modules
+++ b/paxlib.modules
@@ -2,6 +2,7 @@
# A
On Tuesday 10 September 2013 01:32:17 Connor Behan wrote:
> On 09/09/13 03:40 AM, R.G. wrote:
> > Could you please insert some multivolume examples in man page?
>
> I thought tar only came with an info page upstream. The tar man page you
> are looking at was probably written by Debian or some othe
On 13 Oct 2015 14:58, Charles Diza wrote:
> > For (2) I suggest using coreutils; 'rm -fr directory should do the trick
> > if you're using GNU rm.
>
> That doesn't work; it gives the same result as using the built-in BSD `rm`
> on OSX.
is your coreutils version up to date ? if so, please send an
On 13 Oct 2015 16:12, Charles Diza wrote:
> On Tue, Oct 13, 2015 at 3:52 PM, Paul Eggert wrote:
> > On 10/13/2015 12:37 PM, Charles Diza wrote:
> >> But the "confdir-14B--" tree is a different story. No such gradual
> >> pruning works, and neither does coreutils' `rm`. (The latter says "No
> >> s
On 03 Nov 2021 15:21, Gregorio Giacobbe wrote:
> As per subject, I discovered a Path Hijack vulnerabilty in the tar binary.
> When using the -z switch for gzip compression/decompression the binary calls
> “gzip” without absolute path, hence allowing the path Hijack.
> While this, in a normal sce
* buffer.c (zip_program): Add const.
* names.c (names_options): Add const.
(file_selection_option): Add const to p.
* suffix.c (compression_suffixes): Add const.
(find_compression_suffix): Add const to p.
* tar.c (options, sort_mode_flag, argp_children, argp): Add const.
(find_argp_option): Add con
with the rise of commodity multicore computing, tar feels a bit antiquated in
that it still defaults to single (de)compression. it feels like the defaults
could & should be more intelligent. has any thought been given to supporting
parallel (de)compression by default ?
i grok that i could just r
On 04 Nov 2021 13:15, Paul Eggert wrote:
> On 11/3/21 22:13, Mike Frysinger wrote:
> > with the rise of commodity multicore computing, tar feels a bit antiquated
> > in
> > that it still defaults to single (de)compression. it feels like the
> > defaults
> > c
The posix standard has been released for over 20 years, and tar has
supported it for almost as long (at least since 2004). The docs have
said the default will change in a future version for almost as long,
so lets finally actually switch it.
* NEWS: Update.
* configure.ac (DEFAULT_ARCHIVE_FORMAT)
On 09 Dec 2021 19:29, Paul Eggert wrote:
> On 12/9/21 18:40, Mike Frysinger wrote:
> > The posix standard has been released for over 20 years, and tar has
> > supported it for almost as long (at least since 2004). The docs have
> > said the default will change in a future
On 10 Dec 2021 08:38, Michał Górny wrote:
> On Thu, 2021-12-09 at 21:40 -0500, Mike Frysinger wrote:
> > The posix standard has been released for over 20 years, and tar has
> > supported it for almost as long (at least since 2004). The docs have
> > said the default wi
Have the build & NEWS files warn that the --format value is changing.
This has been documented in the manual for almost 20 years, but not
everyone reads the manual.
* NEWS: Update
* README: Document DEFAULT_ARCHIVE_FORMAT will be changing.
* configure.ac: Add warning if DEFAULT_ARCHIVE_FORMAT is n
On 10 Dec 2021 17:23, Paul Eggert wrote:
> On 12/10/21 16:43, Mike Frysinger wrote:
> > POSIX formally standardized this over 20 years ago.
>
> Well, to be fair POSIX standardized both pax and ustar format, and
> they're both still part of the POSIX standard. Switching
The posix standard has been released for over 20 years, and tar has
supported it for almost as long (at least since 2004). The docs have
said the default will change in a future version for almost as long,
so lets finally actually switch it.
* NEWS: Update.
* configure.ac (DEFAULT_ARCHIVE_FORMAT)
On 11 Dec 2021 18:56, Paul Eggert wrote:
> On 12/10/21 20:31, Mike Frysinger wrote:
> > i think the take away is that GNU tar moves the ecosystem. if it changed
> > its default to pax, then projects would be more incentivized to update.
>
> Yes, it's the class
On 13 Dec 2021 01:19, Paul Eggert wrote:
> If the goal is to move GNU tar to generate ustar or pax format by
> default, none of these problems are insuperable; we can eventually get
> people to read the tarballs.
imo, this is the goal for GNU tar
> But if the goal is to generate tarballs
> tha
On 13 Dec 2021 12:30, Sergey Poznyakoff wrote:
> Regarding reproducible build concerns, expressed by Paul: I don't
> believe it is an issue. Reproducible tarballs in PAX format are
> easily made with the following option:
>
> --pax-option=exthdr.name=%d/PaxHeaders/%f,atime:=0,ctime:=0
>
> (btw
On 14 Dec 2021 11:33, Paul Eggert wrote:
> On 12/13/21 21:56, Mike Frysinger wrote:
> > for automake, the limitations in the default v7 catch people off guard (like
> > filename limits).
>
> This is a good reason to switch formats. That being said, a downside of
>
On 16 Dec 2021 18:28, Antonio Diaz Diaz wrote:
> 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
if you have a tar full of 000 dirs, extracting as a non-root user will cause
errors as tar changes the permissions on the directory to 000 before
extracting the subfiles/subdirs
example tar:
http://bugs.gentoo.org/attachment.cgi?id=93830
-mike
pgpfiCLycdDcL.pgp
Description: PGP signature
_
a user pointed out that 1.15.92 behaves differently from 1.15.91 and older and
this tends to break things ... for example:
$ touch foo.txt
$ tar cf - foo.txt > foo.tar
$ tar tf foo.tar
foo.txt
$ tar cvf - foo.txt > foo.tar
$ tar tf foo.tar
tar: This does not look like a tar archive
tar: Skipping
can we get the output of tar sorted when doing tests ? it sometimes fails
exclude.at due merely to the output being in a different order
-mike
signature.asc
Description: This is a digitally signed message part.
# -*- compilation -*-
12. exclude.at:23: testing ...
./e
On Thursday 12 July 2007, Hugh Sasse wrote:
> On Thu, 12 Jul 2007, Benno Schulenberg wrote:
> > Sergey Poznyakoff wrote:
> > > You can configure info to work any way you want (see below).
> >
> > !! How is one supposed to find that? When searching `info info`
> > for "bind" it finds nothing, when
On Tuesday 10 July 2007, Sergey Poznyakoff wrote:
> If it is their choice to provide it, then let them provide it. Some of man
> pages I saw (those distributed with Slackware, for example)
> contain much more info than help2man would produce, and we'd do their
> users a very doubtful favor if we re
On Tuesday 17 July 2007, Sergey Poznyakoff wrote:
> Mike Frysinger <[EMAIL PROTECTED]> ha escrit:
> > is allowing someone to maintain it for tar out of the question ?
>
> Not at all. On the contrary, whoever volunteers to undertake this job
> will be heartily welcomed.
43 matches
Mail list logo
