Hello,
tar (it seems that at least version from 1.23 to 1.26) fails to sync the
archive contents against archived directory with the '--update' option
when changing directory (the -C option) is active.
Original report by Nicolas Mitsis:
https://bugzilla.redhat.com/688567
Steps to
It looks like the only problem was that target children of given
directory 'dir' (these files are expanded on update.c:160) were not
inheriting the 'name-change_dir' info from its parent. Could you
please consider proposed fix in attachement? Separate test-case is also
attached.
I'm trying to
Hi tar community,
we are working on the xattrs|selinux|acl listing feature for command
tar -tf --xattrs and tar -tvf --xattrs (or --selinux, --acls)
and we would like to consult possible format of listing output even if
xattr support is not yet upstream.
There are few existing
Hello Paul, thanks for your comment!
Something like that looks reasonable.
One major comment, though, is that the output of
tar should be parsable, i.e., it should be possible
to look at the output, figure out what format it is,
and parse it reliably. The current format doesn't have
that
Hello, currently the tar's bootstrap fails while doing symbolic link to
non-existing file:
gnulib/build-aux/missing
The last think bootstrap does for me is:
./bootstrap: ln -fs ../gnulib/build-aux/install-sh build-aux/install-sh
.. and after that fails silently with error code 1.
From: Pavel Raiskup prais...@redhat.com
Date: Wed, 15 Aug 2012 16:55:27 +0200
Subject: [PATCH 1/3] Test for bad cooperation of --wildcard and --update
options.
---
tests/Makefile.am | 1 +
tests/testsuite.at | 1 +
tests/update03.at | 43 +++
3 files
I forgot to attach one patch containing fix for testsuite. Attaching now.
Sorry for that,
Pavel
* Note that I changed the temporary patch 0001-* for gnulib also in
gnulib-mailing list.
From ea08ea37712022411226e821c4f7cc429bd64724 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais
I've held off through a combination of wanting to stay as close as
possible to the upstream sources and an apparently erroneous assumption
that with several xattr patches floating around that eventually one
would be merged.
What's the story here? Are there plans to add xattr support to tar?
FWIW, both star and bsdtar support xattrs on Linux.
It would be nice if GNU tar were compatible with those existing
implementations.
Thanks Tim, yes -- xattr-patched GNU tar would be unable to extract
extended attributes from archives created by BSD tar now. In BSD tar
pax headers you are
I'd like ChangeLog entries so that everything is properly credited.
Thanks.
Paul, I miss that ^^ sorry - I'm afraid that building a meaningful
changelog for xattr patch is impossible even for me now. I tried to
comment important parts of patch in the code. If there is something you
don't
On Mon, 2012-10-08 at 15:24 -0700, Paul Eggert wrote:
On 10/08/2012 08:52 AM, Pavel Raiskup wrote:
we are not able to store/restore extended attributes containing '='
character in the keyword properly - same situation in star as our patch
uses the same approach.
Can't we fix this by URL
-case to tar's testsuite also.
For more info see this thread:
http://lists.gnu.org/archive/html/bug-tar/2012-10/msg00017.html
Pavel
From c2afa4fd0a3e71b7a069af5d14b61db217563f3c Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Tue, 9 Oct 2012 15:38:38 +0200
Subject: [PATCH
On Tue, 2012-10-09 at 21:31 -0700, Tim Kientzle wrote:
On Oct 9, 2012, at 12:57 AM, Pavel Raiskup wrote:
On Mon, 2012-10-08 at 15:24 -0700, Paul Eggert wrote:
On 10/08/2012 08:52 AM, Pavel Raiskup wrote:
we are not able to store/restore extended attributes containing '='
character
BTW: converting name/value pairs with unknown meaning into something
different (as UTF-8) may cause problems and is not needed as the meta
data in extended tar headers is binary clean due to it's length tag.
Jorg, the problem is that the character '=' may really cause problems.
Stored xtended
On Wed, 2012-10-10 at 12:42 +0200, Joerg Schilling wrote:
Pavel Raiskup prais...@redhat.com wrote:
BTW: converting name/value pairs with unknown meaning into something
different (as UTF-8) may cause problems and is not needed as the meta
data in extended tar headers is binary clean due
On Wed, 2012-10-10 at 11:52 +0200, Joerg Schilling wrote:
Ondrej Vasik ova...@redhat.com wrote:
AFAIK Red Hat has already signed FSF papers for all employees if the
developed patch is part of the work (at least it was the case for
coreutils, but I assume this is the same for GNU tar).
Previously, if user specified as the second or subsequent multivolume part
bad file of size *smaller* than tar header size, tar did not complained
anything about this mistake and asked for the same volume again.
---
src/buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Actual version of tar fails with segfault when the name of currently
extracted file is longer than 99 bytes, the file is split among more than
one part and user gives to tar bad second or subsequent volume name (the
situation occurs very easily when user does not know what to do when tar
asks for
Do not fail when second or subsequent name of volume is bad. This bug is
covered by multiv09.at test.
* src/buffer.c: Update to not fail.
---
src/buffer.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/buffer.c b/src/buffer.c
index 562996f..6789907 100644
---
?
Pavel
From ce21d1046792a3a918ef85037a28216350511a06 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Fri, 25 Jan 2013 13:24:23 +0100
Subject: [PATCH] sparse: Fix bug in POSIX_FORMAT
Archive the file size correctly (and do not fail) when the shrunken size of
file is = 8^11
Hi Paul,
Thanks for catching that bug. We don't yet have a facility
for large test cases, so I guess we can put that on the todo list.
I agree (this is probably about paxutils?).
Your patch doesn't feel quite right, as there's a similar
issue in pax_dump_header_0, and also there's a
On Mon, 2013-01-28 at 10:17 +0100, Pavel Raiskup wrote:
Hi Paul,
Thanks for catching that bug. We don't yet have a facility
for large test cases, so I guess we can put that on the todo list.
I agree (this is probably about paxutils?).
Your patch doesn't feel quite right, as there's
On Mon, 2013-01-28 at 14:59 +0100, Pavel Raiskup wrote:
On Mon, 2013-01-28 at 10:17 +0100, Pavel Raiskup wrote:
Hi Paul,
Thanks for catching that bug. We don't yet have a facility
for large test cases, so I guess we can put that on the todo list.
I agree (this is probably about
in st_size.
Attached another attempt.
Pavel
From 25ff37fb487e73cf600b7fb877e20944fdb058b6 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Tue, 29 Jan 2013 10:39:30 +0100
Subject: [PATCH] Fix bug in sparse file listing
List posix archives containing sparse files 8GB
Hi all,
I'm just trying to look at the bug here:
https://bugzilla.redhat.com/819187
In short, there would be nice to allow maintainers to specify something
like this:
./configure --with-lzma=xz --format=lzma
This is somehow related to --use-compress-program and this
On Tue, 2013-01-29 at 14:16 -0800, Paul Eggert wrote:
On 01/29/13 08:19, Pavel Raiskup wrote:
Simple speaking, we need some function like:
char ** string_to_argv(const char *str);
I was unable to find existing solution in gnulib
Hi, the same problem as in GNU tar is still in paxutils:
http://git.savannah.gnu.org/cgit/tar.git/commit/?id=6bd463c97e762874511372386a1f6b11f2acc7f5
[PATCH] bootstrap: don't expect the 'missing' script exists in gnulib
Pavel
* bootstrap (gnulib_extra_files): Remove '$build_aux/missing'.
---
bootstrap | 1 -
1 file changed, 1 deletion(-)
diff --git a/bootstrap b/bootstrap
index b7dc9fd..c184789 100755
--- a/bootstrap
+++ b/bootstrap
@@ -104,7 +104,6 @@ tests_base=tests
# Extra files from gnulib, which override files
Do not call wordsplit on multiple places when not necessary.
* system.c (sys_child_open_for_compress): Trim line.
(run_decompress_program): Do not call wordsplit - rather reuse xexec.
(sys_exec_command): Remove unused variable argv.
---
src/system.c | 40 +---
In short, there would be nice to allow maintainers to specify something
like this:
./configure --with-lzma=xz --format=lzma
I have pushed the necessary fixes (commit 7b5e8039). Any option taking
a command name as its argument now accepts a full command line as well.
These
On Wed, 2013-02-20 at 16:28 +0300, Sergey Poznyakoff wrote:
Pavel Raiskup prais...@redhat.com ha escrit:
Move the xexec function into #ifndef MSDOS part of file.
Yes, that's reasonable.
* system.c (try_exec): New function - modified previous xexec.
This will cause a memory leak
Do not call wordsplit on multiple places when not necessary.
Move the xexec function into #ifndef MSDOS part of file.
* system.c (try_exec): New function - modified previous xexec.
(xexec): Re-use try_exec and fail when not try_exec unsuccessful.
(run_decompress_program): Do not call wordsplit -
now (and its
development then). Everybody must use
./configure --disable-gcc-warnings.
On Wed, 2013-02-20 at 15:09 +0300, Sergey Poznyakoff wrote:
Pavel Raiskup prais...@redhat.com ha escrit:
Do not call wordsplit on multiple places when not necessary.
(run_decompress_program): Do
Sorry for trashing CC list, recovering..
It seems that it comes from mailutils (but not mentioned in your patch
- not in mailutils)
Actually it is not. It comes from one of my projects:
https://puszcza.gnu.org.ua/projects/grecs
and I synchronize it with mailutils from time to
We should overwrite the size when realsize has not been specified, not
just when our size exceeds what's in st_size.
Attached another attempt.
Paul, what do you think?
Thanks, Pavel
On Thu, 2013-02-21 at 09:26 -0800, Paul Eggert wrote:
On 02/21/13 05:37, Pavel Raiskup wrote:
Paul, what do you think?
Sorry, I've lost context. Is there a test case illustrating
the bug that this fixes?
Just prepare sparse file of effective size 8GB and try to create --posix
tarball
see in this patch, but feel free to scratch
this and fix it by different way ;),
Thanks for comments!
Pavel
From e337d29ad24ae5b3b4c07a6287e9b44b37c59dcb Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Mon, 25 Feb 2013 10:18:15 +0100
Subject: [PATCH] tar: The Lempel-Ziv
output is larger
|then original data.),
|(unsigned long) child_pid));
| #endif
From 3281269662a7d361ef8a360600352e93cc2ebdcf Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Mon, 25 Feb 2013 10:18:15 +0100
Subject: [PATCH] tar
is obsolete and isn't likely to change so this sounds safe.
Thanks for comments! Attaching approach with just src/system.c
and NEWS edited.
Pavel
From eab80fb7c5a5500a9d4c20321b4f00e019cb3735 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Mon, 25 Feb 2013 10:18:15 +0100
Subject
Hi, with the default configuration of GNU tar, the build fail on PowerPC 64
bit
machine with:
Some additional info:
$ rpm -q glibc gcc
glibc-2.16-28.fc18.ppc64p7
gcc-4.7.2-8.fc18.ppc64
Pavel
On Fri, 2013-03-22 at 12:56 -0600, Bob Proulx wrote:
Antonio Diaz Diaz wrote:
May I suggest that megabyte-sized text files be attached compressed:
Yes, please.
Really sorry for that - I missed the size.
I reinstated the typical 100K limit.
Thanks a lot for this ^^^ and for all your work!
On Tuesday, February 26, 2013 08:32:25 AM Pavel Raiskup wrote:
On Mon, 2013-02-25 at 11:39 -0800, Paul Eggert wrote:
I suggest something simpler: namely, just declare that the
-Z (compress) program must conform to the compress API,
so that its exit status 2 really means OK. That way,
we
On Friday, November 02, 2012 02:45:40 PM Pavel Raiskup wrote:
Hello,
could you please consider following series of patches:
[PATCH 1/5] Make the multi-volume code more generic
- low prio - just avoid code duplication
[PATCH 2/5] New test for extraction of multi-volume archives
On Wednesday, April 24, 2013 11:17:54 AM Stefano Lattarini wrote:
Without this change, building from the bootstrapped Git repository
with GCC (4.7.2) fails like this:
xattrs.c:488:1: error: ‘xattrs__fd_set’ defined but not used \
[-Werror=unused-function]
cc1: all warnings being
On Wednesday, April 24, 2013 10:58:10 PM 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.
When tar infers a compressor it can also infer which of these two
options to use.
That means, using the -Z, -z, .. options will setup some new flag, same
as the new use-compress-program-like option will. Do you have some
requirements for this option name? This is the hard one..
Would you be
On Friday, April 26, 2013 01:36:02 AM Paul Eggert wrote:
On 04/26/2013 01:17 AM, Pavel Raiskup wrote:
Do you have some
requirements for this option name?
We could have --use-compress-program for the compress API,
and --use-filter-program for the more-vanilla API.
Or something like
Obsolete the --use-compress-program by the --filter-program
option (same sematics). Add new option --compress-program.
Use '--compres-program'-like API by the -Z, but also by -z, -J,
--lzop and --lzma options. Use '--filter-program'-like interface
by -j and --lzip.
See also:
Hi Antonio, thanks for comments,
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
On Sunday, April 28, 2013 07:23:05 PM Antonio Diaz Diaz wrote:
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.
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.. Simply, it makes sense to work on this only if the upstream is
really
And I cannot get what should be default tar acl behaviour?
Thanks for your comment, I missed that the documentation part was not
pushed upstream:
http://lists.gnu.org/archive/html/bug-tar/2012-08/txt_YmFUlb7zE.txt
Option --acls used to be default
ACLs are new in _upstream_ GNU tar.
and now
I was aked in our bugzilla to add warning for --xattrs-include which does
not imply the --xattrs. Would there be considered attached patch adding
this warning? Thanks, Pavel
From 517433b7f8e14b20c73b9ffb7fe3210186bbb611 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Thu
I would rather say that both --xattrs-include and --xattrs-exclude should
imply --xattrs.
Attached.
From ec4527a90e9ab7cbf8177022f493670090912a23 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Thu, 23 May 2013 11:36:23 +0200
Subject: [PATCH] tar: imply --xattrs when
* configure.ac: Use AC_ARG_VAR([RSH],[...]).
---
configure.ac | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure.ac b/configure.ac
index 3303c53..a4e2301 100644
--- a/configure.ac
+++ b/configure.ac
@@ -217,6 +217,7 @@ AC_CHECK_DECLS([time],,, [#include time.h])
: Skipping to next header
Aborted (core dumped)
Original report is here:
http://bugzilla.redhat.com/977807
Pavel
From 6a5eb6b3a15be6649cff10a8978efc1a1747544c Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Wed, 26 Jun 2013 16:03:01 +0200
Subject: [PATCH] tar: fail
I've fixed that in the repository (cfebb3ce).
Thanks! Small fix (iirc) is needed for --occurence option. Before this
commit, --occurence was available also for DELETE_SUBCOMMAND. Now it is
available just for SUBCL_READ (which does not cover --delete).
. It was easily reproducible on my Fedora 19 box.
Possible fix is in attachment, Pavel
From 87c6b8e31c5f9b33d0ba458e6a40152f130262ae Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Tue, 23 Jul 2013 12:01:36 +0200
Subject: [PATCH] tar: fix -T option for empty and corrupted
I have installed the following patch, which fixes both the bugs in
-T handling discovered by Michal and reduces the memory consuption to
an acceptable level (the bug was reported by Christian).
Thanks, I'm observing build fails now:
...
CC incremen.o
CC list.o
CC
From: Pavel Raiskup prais...@redhat.com
Date: Thu, 15 Aug 2013 11:43:17 +0200
Subject: [PATCH] tar: fix use of uninitialized memory
This complements 26538c9bf.
* src/names.c (name_add_file): Initialize the ep-v.file.fp pointer
after structure allocation.
* tests/testsuite.at: Export
- the semantics of -T option changed in relation to -C option. I am
unable to find any note in changelog that this is expected - so I'm just
not sure. Do you really want that?
Actually, yes. I think that -C should affect all options that follow
it. I indeed failed to list that in
So perhaps tar should allow subsequent (as opposed to recursive) reads of
the same file?
Ahh, I see now what happens there :), thanks. Yes. That would make
sense.
.. do we really need to parse all options? Wouldn't it be better to
artificially bound the -T FILE parsing power? I mean, this
Thanks for update, I haven't found time for proper review of
chagnes, but the testsuite (after applying this patch) works for
me.
Pavel
---
tests/T-cd.at | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tests/T-cd.at b/tests/T-cd.at
index ac76021..d8fcd88 100644
---
Usage of --starting-file and --same-order options make sense only
for reading operations.
* src/tar.c (decode_options): Fail for incompatible subcommand.
(options): Adjust help output.
---
src/tar.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/tar.c
Hello, here comes ping on several topics for which I posted some patches/ideas
before; these need to be refreshed a little.
I don't want to kick you to push my changes — what I need now is just hear
which ideas are planned to be used in future and which of them I should
completely scratch and
#define ST_IS_SPARSE(st) \
(ST_NBLOCKS (st)\
- ((st).st_size / ST_NBLOCKSIZE + ((st).st_size % ST_NBLOCKSIZE != 0)))
+((st).st_size / ST_NBLOCKSIZE \
+ + ((st).st_size % ST_NBLOCKSIZE
To be clear, I can see that the fix to ST_IS_SPARSE should cause
dump_regular_file to be called instead of sparse_dump_file, but I still
wonder if it is wise to leave this logic in place. At the very last,
I think a comment would be helpful to explain that this test is valid
only because
On Saturday, December 07, 2013 00:27:44 Linda A. Walsh wrote:
I usually look in the manpage. There's not even a link to the
URL, below, that you mention.
GNU tar upstream does not provide manual page. The page you see is
probably distro-specific. E.g. in Fedora we have (mostly) generated
On Monday, December 09, 2013 00:02:41 Joerg Schilling wrote:
Tim Kientzle kient...@acm.org wrote:
Pavel recently sent me an archive created with GNU tar
that includes SCHILY.xattr extensions.
I would guess that the problem is not SCHILY.xattr extensions in general but
a buggy
i Anthony, thanks for looking at it! I haven't test it, but here is
static analysis:
diff --git a/acinclude.m4 b/acinclude.m4
index d48c881..18cfd49 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -37,18 +37,40 @@ AC_DEFUN([TAR_HEADERS_ATTR_XATTR_H],
[], [with_xattrs=maybe]
)
I haven't found --diff feature test case in conjunction with
--listed-incremental so here it is. This is check for regression
fixed by commit d88b2a613f4.
* tests/incr10.at: New testcase.
* tests/Makefile.am: Add new testcase.
* tests/testsuite.at: Likewise.
---
tests/Makefile.am | 1 +
Hi, looking at savannah page for GNU tar/cpio, it seems that
patch/bug submission is not watched by maintainers for some
time.. Could we expect that submission there is still valid
way how to propose patches upstream? If not, it would be
nice to remove that option to not confuse people (at least
On Wednesday, January 08, 2014 23:52:47 Karl Berry wrote:
Hi Sergey/all - when make check fails, it advises the user to email
testsuite.log to bug-tar. That is nice in theory, but the log is big
these days, and there are a lot of people on bug-tar, ie, we're talking
a lot of bandwidth to
I'd like to remember of the following bug report and to announce that I
have finished patches for all these issues.
Marcus, thanks for looking at this problem. I think fixes for
ACLs/capabilities are really important, though I have not looked at your
code yet.
I have submitted my patches to
Hello,
what are the reasons to not take member name argument './file' and 'file'
equivalently? So far I found only one point in documentation that it is
essential because tar preserves filenames (2.7. How to List Archives).
Thanks, Pavel
On Friday, January 17, 2014 11:21:34 Joerg Schilling wrote:
Pavel Raiskup prais...@redhat.com wrote:
what are the reasons to not take member name argument './file' and 'file'
equivalently? So far I found only one point in documentation that it is
essential because tar preserves filenames
to test_domain: resolve failed
Fix for paxutils attached.
Pavel
From 55b126fe51e443eef1191f43b91c319135489453 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Wed, 29 Jan 2014 12:29:20 +0100
Subject: [PATCH] paxutils: use getaddrinfo instead of gethostbyname
Also validate
something).
OT: I'd like to mention also one forgotten patch:
http://www.mail-archive.com/bug-tar@gnu.org/msg04052.html
Pavel
testsuite.log.gz
Description: application/gzip
From 221aac36af214316c0a216a1facd586cb115fa0d Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Mon
Hi Connor, Sergey,
Haven't checked the '--one-top-level' option implementation yet. I tried
what it causes in listing mode, it segfaults ATM:
| $ ./src/tar -tf test.tar --one-top-level
| Segmentation fault (core dumped)
| $ gdb --args ./src/tar -tf test.tar --one-top-level
| Reading symbols
] http://www.mail-archive.com/bug-tar@gnu.org/msg04199.html
Thanks for any comment,
Pavel
PS: Use --ignore-space-change due to some indentation changes
From ab4c08ccc5f0baa1b4ab3e524b50013b33b94d45 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Sun, 23 Feb 2014 13:12:54 +0100
Hello Linda,
On Tuesday, March 04, 2014 15:38:22 Linda A. Walsh wrote:
Pavel Raiskup wrote:
When --acls option is on (regardless of tarball contents or
tarball format), we should explicitly set OR delete default ACLs
for extracted directories. Prior to this update, we always
created
On Wednesday, March 05, 2014 12:14:17 Joerg Schilling wrote:
Pavel Raiskup prais...@redhat.com wrote:
Note that after discussion [1] I still think that existing ST_IS_SPARSE
macro is better for file-sparseness detection than using SEEK_HOLE (not
worth having additional syscalls open~seek
On Wednesday, March 05, 2014 05:06:06 Linda A. Walsh wrote:
Pavel Raiskup wrote:
Or could you give an example? What *exactly* do you expect the --acls
should behave by default? Combine existing acls in parent directory
(default acls) with the stored in archive?
Thanks, Pavel
Hello Dan,
I have an issue with tar, it seems tar manages to create archive of
files larger than 8GB how ever, the header becomes curropted and thus
tar is unable to extract the archive.
what format are you using?
The 'pax' format (e.g.) is able to store files larger than 8GB and it
works
On Wednesday, March 12, 2014 11:00:14 Paul Eggert wrote:
I cannot reproduce the bug with tar 1.27.1 (which I built for Fedora 20
x86-64). Can you please give a recipe? Here's how I tried:
Dan replied to me off-list accidentally. The problem was just misuse of
tar's options (tar -x
On Wednesday, March 12, 2014 16:08:58 Paul Eggert wrote:
Pavel Raiskup wrote:
We should probably detect terminal archive input/output and fail
appropriately?
tar always does something like that. Sorry, I don't understand the
failure scenario here.
We could detect that archive contents
to find proper 'script'
alternative tool among coreutils, is there some? I could rewrite it then.
Pavel
From 57a95aff7d9ff9f257d934f823b7e4b1ae276caf Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Thu, 13 Mar 2014 08:58:42 +0100
Subject: [PATCH] tar: fail if archive comes
On Thursday, March 13, 2014 09:21:44 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 meant something like the patch attached, could you
On Thursday, March 13, 2014 09:35:26 Paul Eggert wrote:
On 03/13/2014 01:21 AM, 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 meant
Eric Blake:
On 03/13/2014 12:00 PM, Paul Eggert wrote:
On 03/13/2014 10:32 AM, Pavel Raiskup wrote:
Strictly
speaking, GNU Coding Guidelines are talking about program_output_
You're right, and I hadn't noticed that. How about doing things the way
xargs does them, as Eric Blake
On Thursday, March 13, 2014 17:19:10 Paul Eggert wrote:
Pavel Raiskup wrote:
Do you feel the patch is acceptable, you feel (or just plan
to) prepare some patch or possibly - should I fix something
in the patch?
I'd like to see Sergey's opinion.
I wanted to say the same :). Sergey?
IIRC, RE_CHECK from testsuite.at has never worked as expected
(never performed any checking until now). So wrapping its
contents by AT_CHECK and double-quote right argument of AT_DATA to
not eat special regex symbols. Avoid awk join.
* tests/testsuite.at (RE_CHECK): Change logic a little.
*
On Friday, March 14, 2014 14:13:35 Sergey Poznyakoff wrote:
Hi all,
I'd like to see Sergey's opinion.
I think we should apply the patch. However, I doubt if the use of
script in the testsuite is OK. I'm going to write a simple auxiliary
program that would use ptys to emulate tty
Hello,
On Saturday, March 15, 2014 09:13:08 e-letter wrote:
Readers,
What is the risk of data corruption if a zip archive is added to a tarball?
If there is in-sufficient space on the local disk that contains the
zip archive, can the zip file be extracted and 'piped' to the tarball
on the
) to make it possible to deal with errors at one
place (stopped once I realized that it will be somehow bigger code
change). Would you be interested in such patch?
Pavel
From c008273c7488e47dbf942ec79e83e95d34ff873f Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Sun, 16 Mar 2014 22
On Tuesday 25 of March 2014 22:51:11 Karl Berry wrote:
rms is ok with the exception for binary output to the terminal, and
wants this text:
There is an exception for programs whose output in certain cases is
binary data. Sending such output to a terminal is useless and can
cause
The default settings of --exclude wildcard matching leads usually
to --no-wildcards-match-slash option but there is not obvious that
users should also turn --no-anchored option on.
* doc/tar.texi: Describe.
---
doc/tar.texi | 67
1
tar: Exiting with failure status due to previous errors
Original bugreport thread:
http://www.mail-archive.com/bug-tar%40gnu.org/msg03905.html
Pavel
From c8c86adf182260182c4ad6cd1991c8808ecf7dbb Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Tue, 1 Apr 2014 13:09:20 +0200
On Thursday 27 of March 2014 19:45:54 Nathan Stratton Treadway wrote:
On Wed, Mar 26, 2014 at 18:43:54 +0100, Vitezslav Cizek wrote:
$ echo bar | tar -cvf t.tar -T -
bar
$ echo bar | tar -cvf t.tar -T -
[...hangs...]^C
Thanks for reproducer! As this is easily scriptable, could we
Hello Vladimir,
On Monday 23 of June 2014 01:22:16 Vladimir A. Pavlov wrote:
It's sometimes useful to ignore errors tar returns if a requested member
is not found in archive,
yes, I think this would be useful,
For example:
$ touch file
$ tar -c file | tar -t file
Just a nit, here should
1 - 100 of 245 matches
Mail list logo
