5db7421492a0bcbb90c7fde17906461bd9dfe4f8 Mon Sep 17 00:00:00 2001
From: Connor Behan connor.be...@gmail.com
Date: Mon, 23 Sep 2013 16:37:10 -0700
Subject: [PATCH] Refuse to create archive for non-existent members
Content-Type: text/plain; charset=utf-8
* src/create.c (dump_file0): Open archive when
ae9fca28961efed9ae643105b15152d149e695d1 Mon Sep 17 00:00:00 2001
From: Connor Behan connor.be...@gmail.com
Date: Thu, 13 Feb 2014 22:33:29 -0800
Subject: [PATCH] Prefer the argument specified to --one-top-level
Content-Type: text/plain; charset=utf-8
* src/tar.c (decode_options): Only deduce
* NEWS: Only document --one-top-level once
---
NEWS | 8
1 file changed, 8 deletions(-)
diff --git a/NEWS b/NEWS
index ea3a27d..4652349 100644
--- a/NEWS
+++ b/NEWS
@@ -52,14 +52,6 @@ version 1.27.1 - Sergey Poznyakoff, 2013-11-17
* Fix extracting sparse members from star archives.
* src/common.h (one_top_level_option): New global.
(one_top_level): New global.
* src/extract.c (extr_init): If one_top_level_option is set, determine
the name one_top_level that might have to be prepended.
(extract_archive): If one_top_level_option is set, prepend one_top_level
to all names that
On 24/01/14 02:45 PM, Sergey Poznyakoff wrote:
Hi Connor,
Due to recent changes in git, I will need to send yet another updated
version.
Yes, I would appreciate it if you could provide a patch to the current
git head.
Thanks: http://lists.gnu.org/archive/html/bug-tar/2014-01/msg00042.html
* src/common.h (one_top_level_option): New global.
(one_top_level): New global.
* src/extract.c (extr_init): If one_top_level_option is set, determine
the name one_top_level that might have to be prepended.
(extract_archive): If one_top_level_option is set, prepend one_top_level
to all names that
Sergey, I would like to hear your opinion on the tarbomb patch currently
residing at http://lists.gnu.org/archive/html/bug-tar/2013-12/msg00035.html
I first sent it to the list in August 2013. I understand that committing
the first version of it so close to a release would not have been a good
On 07/01/14 11:35 AM, Sergey Poznyakoff wrote:
Pavel Raiskup prais...@redhat.com ha escrit:
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
* src/common.h (one_top_level_option): New global.
(one_top_level): New global.
* src/extract.c (extr_init): If one_top_level_option is set, determine
the name one_top_level that might have to be prepended.
(extract_archive): If one_top_level_option is set, prepend one_top_level
to all names that
* src/common.h (one_top_level_option): New global.
(one_top_level): New global.
* src/extract.c (extr_init): If one_top_level_option is set, determine
the name one_top_level that might have to be prepended.
(extract_archive): If one_top_level_option is set, prepend one_top_level
to all names that
* src/common.h (one_top_level_option): New global.
(one_top_level): New global.
* src/extract.c (extr_init): If one_top_level_option is set, determine
the name one_top_level that might have to be prepended.
(extract_archive): If one_top_level_option is set, prepend one_top_level
to all names that
On 27/11/13 08:25 AM, Joshua Hudson wrote:
It is my opinion this patch is incorrect in design.
If I were to arrange for the first file to be .bashrc, you would get the
error, but the damage would already be done.
Good point. The patch prevents the clutter of a tarbomb but it wouldn't
be able
* src/common.h (one_top_level_option): New global.
* src/extract.c (extract_archive): If one_top_level_option is set, check
for whether the archive tries to create two file trees.
* src/tar.c (ONE_TOP_LEVEL_OPTION): New constant.
(options): New option --one-top-level.
(parse_opt): Handle this
On 10/11/13 05:47 PM, Linda A. Walsh wrote:
On openSuse, w/tar-1.26-17.1.x86_64, I tried using
the --portability flag to get only older headers..
Instead I got:
tar cf out --portability P-1.1.4/
tar: --old-archive: (PROGRAM ERROR) Option should have been recognized!?
Try `tar --help' or
On 29/10/13 01:09 PM, Connor Behan wrote:
Hello. Since the GNU tar 1.27 release, I have updated my patch for
limiting the top-level names extracted to one:
http://lists.gnu.org/archive/html/bug-tar/2013-10/msg3.html
Do you think there are any remaining problems with it? I have read
On 17/10/13 04:20 PM, Charles Swiger wrote:
Hi--
On Oct 17, 2013, at 2:10 AM, devkumar@bt.com wrote:
Hi GNU Team,
Well, this is a mailing list for GNU tar, but there are a number of non-GNU
folks lurking around here. :-)
This is regarding the creation of tar archive from files
* src/common.h (one_top_level_option): New global.
* src/extract.c (extract_archive): If one_top_level_option is set, check
for whether the archive tries to create two file trees.
* src/tar.c (ONE_TOP_LEVEL_OPTION): New constant.
(options): New option --one-top-level.
(parse_opt): Handle this
* src/common.h (one_top_level_option): New global.
* src/extract.c (extract_archive): If one_top_level_option is set, check
for whether the archive tries to create two file trees.
* src/tar.c (ONE_TOP_LEVEL_OPTION): New constant.
(options): New option --one-top-level.
(parse_opt): Handle this
* src/common.h (one_top_level_option): New global.
* src/extract.c (extract_archive): If one_top_level_option is set, check
for whether the archive tries to create two file trees.
* src/tar.c (ONE_TOP_LEVEL_OPTION): New constant.
(options): New option --one-top-level.
(parse_opt): Handle this
On 23/09/13 02:16 AM, Joerg Schilling wrote:
Pulkit Bhuwalka pulkit.bosc...@gmail.com wrote:
Hi,
This is to report an issue that I have run into while using tar.
*Issue* - tar destroys file when arguments are passed in wrong order
leading to loss of data.
*Correct tar order* - tar -cvzf
causing tar to bail in mid-extraction as soon as it determines
that the archive is of the type mentioned above. It would be up to the
user to subsequently apply shell commands to contain these archives.
Signed-off-by: Connor Behan connor.be...@gmail.com
---
NEWS | 10 ++
doc
Hello, now that commits are happening again and a release is being
discussed, I'd like to ask about my patch to let the user limit
top-level extracted names to 1.
http://lists.gnu.org/archive/html/bug-tar/2013-08/msg00032.html
I posted v3 of my larger patch on the same day, but the above takes
On 09/09/13 03:40 AM, R.G. wrote:
Hi !
Recently i have had to extract a multivolume tar file. It was my first
time doing such things and of course i opened tar man page. The
possibility of sending data for tar through standard input (via and
) was not mentioned there (i think it should be).
Hi, as you might know I sent three patches to the list on August 17.
http://lists.gnu.org/archive/html/bug-tar/2013-08/msg00031.html
http://lists.gnu.org/archive/html/bug-tar/2013-08/msg00032.html
These tarbomb patches were controversial so I could understand if
further changes are needed here.
as many unpleasant surprises. Various workarounds could then be
used on an individual basis.
Signed-off-by: Connor Behan connor.be...@gmail.com
---
doc/tar.texi | 7 +++
src/common.h | 3 +++
src/extract.c | 23 +++
src/tar.c | 7 +++
4 files changed, 40 insertions
extraction the new option conditionally creates a
directory derived from the basename of the archive, falling back to the
usual method if the directory already exists.
Signed-off-by: Connor Behan connor.be...@gmail.com
---
doc/tar.texi | 14 ++
src/common.h | 3 +++
src/extract.c | 87
* src/names.c: Strict definition of file_list_name.
Signed-off-by: Connor Behan connor.be...@gmail.com
---
src/names.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/names.c b/src/names.c
index 0eff2b4..4f69577 100644
--- a/src/names.c
+++ b/src/names.c
@@ -349,7 +349,7
On 13/08/13 08:56 PM, Paul Eggert wrote:
Connor Behan wrote:
This could be handled without adding a new option
if -k became don't replace existing files or create more than one file
at the top level when extracting, treat them as errors. So -k would
become a broader kind of play it safe
On 12/08/13 01:25 PM, Paul Eggert wrote:
I'm still not sold on this idea; I think it's too intelligent,
the documentation is hard to understand, and it'll be hard to
explain to users.
Could someone please explain why the '-k' option (which already
exists) doesn't solve the problem? Perhaps
On 07/08/13 08:13 PM, Paul Eggert wrote:
I don't see why this option would help much.
All it takes to corrupt is one file, right?
And I can see weaknesses in the proposed implementation:
when you rename the extracted file, you might rename
a file that already existed.
Nothing gets
files, directories and links.
Signed-off-by: Connor Behan connor.be...@gmail.com
---
doc/tar.texi | 12 ++
src/common.h | 3 +++
src/extract.c | 74 +++
src/tar.c | 11 +
4 files changed, 100 insertions(+)
diff --git a/doc
31 matches
Mail list logo
