Re: [Bug-tar] tar-1.15.1+: numerous bugs in xheader.c

Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: ... Here's a patch that fixes all of the above problems: I reviewed it and found a bunch more problems in the neighborhood, mostly having to do with time stamp handling. I installed the following patch, which fixed

Re: [Bug-tar] closed stderr can make tar corrupt its output archive

Sergey Poznyakoff [EMAIL PROTECTED] wrote: Hi Jim, - in --create mode, with a named target (i.e., not stdout), - with stderr closed, and - in a way that provokes tar to write a diagnostic, then tar corrupts the named output archive by writing the diagnostic it. Thanks for reporting

[Bug-tar] argp --help infloop bug

You can make any argp-using program infloop simply by running it with --help and with something like ARGP_HELP_FMT=rmargin=a in the environment. Or use a valid (but small) width: ARGP_HELP_FMT=rmargin=2 $ time ARGP_HELP_FMT=rmargin=2 tar --help /dev/null ARGP_HELP_FMT=rmargin=2 tar --help

[Bug-tar] Re: argp --help infloop bug

Sergey Poznyakoff [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] wrote: You can make any argp-using program infloop simply by running it with --help and with something like ARGP_HELP_FMT=rmargin=a in the environment. Or use a valid (but small) width: ARGP_HELP_FMT=rmargin=2 Yes

[Bug-tar] `make install' failure with latest CVS sources

Hi Sergey, When running `make install' with the latest CVS sources, I get lots of errors like this: mkdir -p -- /locale/zh_TW/LC_MESSAGES mkdir: cannot create directory `/locale': Permission denied /p/bin/install: cannot create regular file `/locale/zh_TW/LC_MESSAGES/tar.mo': No such file

[Bug-tar] avoid compiler warnings, adapt to latest gnulib

Hi Sergey, tar doesn't build against the latest gnulib. Here is a patch to fix that, along with changes to avoid a bunch of warnings: 2007-08-25 Jim Meyering [EMAIL PROTECTED] Don't include getline.h. No longer needed. * src/incremen.c: Don't include getline.h. No longer

[Bug-tar] Don't read from name[-1].

2007-11-12 Jim Meyering [EMAIL PROTECTED] Don't read from name[-1]. * src/incremen.c (make_directory): Handle namelen == 0, since find_directory_meta calls make_directory (). Index: src/incremen.c === RCS

Re: [Bug-tar] tar -vf /dev/stdout produces corrupted archives

Radek Brich [EMAIL PROTECTED] wrote: On Tue 11. of December 2007 13:55:53 you wrote: Radek Brich [EMAIL PROTECTED] ha escrit: Although it'd need some cleaning, I'd like to hear what you think about the idea? Generally speaking, looks nice, except that fstat may fail (e.g. if stdout is

[Bug-tar] duplicate header inclusion

Hi Sergey, src/xheader.c includes fnmatch.h twice.

Re: [Bug-tar] [PATCH] tar: more reliable directory traversal when creating archives

Paul Eggert wrote: I installed this: * NEWS: Document this. * gnulib.modules: Add openat, readlinkat. * src/common.h (open_read_flags, fstatat_flags): New global variables. (cachedir_file_p, dump_file, check_exclusion_tags, scan_directory): Adjust to new signatures, described below.

Re: [Bug-tar] [PATCH] tar: more reliable directory traversal when creating archives

Paul Eggert wrote: On 09/07/2010 02:37 AM, Jim Meyering wrote: on NetBSD 5.0.2 it's just 128. While most distribution tarballs fit easily within such a limitation, when you use tar to perform backups, you might find such a low number to be a serious limitation. Even 1024 seems far too low

[Bug-tar] [PATCH] tests: avoid spurious failure when VERSION_CONTROL envvar is set

I ran make check for tar-1.25 and saw a failure: 49: extracting existing dir with --backup FAILED (backup01.at:36) Here's a fix: From fbbcca7da693ffec258a135d9da857929b9964b9 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Mon, 8 Nov 2010 19:59:42 +0100

[Bug-tar] [PATCH] tests: avoid filerem01 failure in massively parallel test

it for me: From e22d60c065166fdf11634bad64f264bfe083e409 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Mon, 8 Nov 2010 21:48:45 +0100 Subject: [PATCH] tests: avoid filerem01 failure in massively parallel test * tests/filerem01.at: Unlink at 2nd checkpoint, not 3rd. --- tests

[Bug-tar] [PATCH] maint: remove now-useless test-before-free

'\s*\((?:\s*\([^)]+\))?\s*\1\s*\))/$2/s' From 7d6b79464e8077b5fcdcaf61c08b5f46be887402 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Fri, 7 Jan 2011 12:40:06 +0100 Subject: [PATCH] maint: remove now-useless test-before-free There is no longer (since SunOS 4) any need

Re: [Bug-tar] an exactly duplicated file was created by tar

Paul Eggert wrote: On 08/18/2011 10:29 AM, Oliver Kullmann wrote: ls -ali 1025185* 7551518 -rw-r--r-- 1 csoliver users 164 2011-08-16 21:23 1025185 7551518 -rw-r--r-- 1 csoliver users 164 2011-08-16 21:23 1025185 This appears to be a bug in the file system, not in 'tar' itself. A directory

Re: [Bug-tar] an exactly duplicated file was created by tar

Joerg Schilling wrote: Jim Meyering j...@meyering.net wrote: This may be due to an NFS problem. Here's a case where readdir would return the same name, yet a new pointer, each time, forever: NFS readdir never returns NULL when processing directories with very many\ entries (i.e

Re: [Bug-tar] tar with -k option no longer warns when not overwriting files

Sergey Poznyakoff wrote: Paul Eggert egg...@cs.ucla.edu ha escrit: is it wise to introduce a new level of verbosity for this? It'd I would prefer a new option, because... be simpler if ordinary -v enabled this new warning, as it does the other warnings, and I'm wondering why the simpler

Re: [Bug-tar] tar with -k option no longer warns when not overwriting files

Sergey Poznyakoff wrote: All of this to say that I hope there is some way to make tar work the way it used to with those options, Up to version 1.22 tar would exit with a non-zero error code in such cases. Do you propose to restore this behavior too? In my opinion, it is inconsistent,

Re: [Bug-tar] --keep-old-files bug

Paul Eggert wrote: On 11/22/11 03:35, Gary Partis wrote: How ever, neither a warning message or exit code indicates that such an error occurred. Thanks, I expect this is a documentation bug that should get fixed. Hi Paul, Isn't this a regression? This is the behavior I deliberately choose

Re: [Bug-tar] --keep-old-files bug

Sergey Poznyakoff wrote: I have installed the attached patch. Thank you! I noticed some trailing blanks added by that patch (a couple marked below) In case you would like to avoid those, here are some preventive measures: Run this to set a global git config option to highlight them in git

Re: [Bug-tar] Documentation bug

Paul Eggert wrote: On 07/26/2012 01:49 PM, Eric Blake wrote: can we always count on the vc-dwim boilerplate to be the same to automatically prune it from gitlog-to-changelog? Probably not, but we can keep a catalog of all of them, surely, assuming this problem persists indefinitely, which I

Re: [Bug-tar] Documentation bug

Sergey Poznyakoff wrote: Jim Meyering j...@meyering.net ha escrit: (BTW, the second sentence seems incorrect: I saw no makefile rule for ChangeLog in tar.) It is in Make.rules, which is imported from Paxutils. Thanks for the info. This particular working directory had an old cvs-based

Re: [Bug-tar] Problem with bootstrap -- missing file 'gnulib/build-aux/missing'

Pavel Raiskup wrote: 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

Re: [Bug-tar] bug#15970: Crash in gettext() after fork() on Mac OS X

Hi Pádraig, Thanks for dealing with that. Your patch looks correct. Did you consider using inttostr in place of that first part of async_safe_error?

Re: [Bug-tar] [PATCH] --one-top-level: avoid a heap-buffer-overflow

On Sun, Apr 8, 2018 at 11:16 AM, Jim Meyering <j...@meyering.net> wrote: > On Sun, Apr 8, 2018 at 1:53 AM, Sergey Poznyakoff <g...@gnu.org.ua> wrote: ... > I see what you mean. So how would you like a NAME of "a.tar.tar" to be > treated? Seems wrong to remove th

Re: [Bug-tar] [PATCH] --one-top-level: avoid a heap-buffer-overflow

On Sun, Apr 8, 2018 at 1:53 AM, Sergey Poznyakoff <g...@gnu.org.ua> wrote: > Jim Meyering <j...@meyering.net> ha escrit: > >> $ : > k && tar cf k.tar k; valgrind tar --one-top-level -tf k.tar >> >> Invalid read of size 1 >> at 0x421FC

Re: [Bug-tar] [PATCH] --one-top-level: avoid a heap-buffer-overflow

On Sun, Apr 8, 2018 at 2:55 PM, Marius Spix wrote: > What is in the case that the suffix is not 3 characters long, e. g. > ".tz" or ".tbz2"? That is already handled by the find_compression_suffix call. It sets "len" to the length not including that trailing suffix. What we're

Re: [Bug-tar] [PATCH] --one-top-level: avoid a heap-buffer-overflow

On Sun, Apr 8, 2018 at 12:34 PM, Jim Meyering <j...@meyering.net> wrote: > On Sun, Apr 8, 2018 at 11:16 AM, Jim Meyering <j...@meyering.net> wrote: >> On Sun, Apr 8, 2018 at 1:53 AM, Sergey Poznyakoff <g...@gnu.org.ua> wrote: > ... >> I see what you mean. So how

[Bug-tar] [PATCH] --one-top-level: avoid a heap-buffer-overflow

e 6 alloc'd at 0x4C2CB6B: malloc (vg_replace_malloc.c:299) by 0x52F07B9: strndup (strndup.c:43) by 0x441948: xstrndup (xstrndup.c:32) by 0x4058F8: decode_options (tar.c:2544) by 0x4058F8: main (tar.c:2708) >From e68608dd3ae21fbdb24caeddc2bba34c265f53b7 Mon Sep 17 00:00:00

[Bug-tar] [PATCH] tests: add coverage for new --zstd and all other compression tools

Hi Sergey, Here is a patch to add tests for --zstd as well as coverage for the other types of compression that tar supports. >From 212c575a1beb5a8193d02f982d2e8fcc2ff45fa1 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyer...@fb.com> Date: Tue, 20 Mar 2018 13:12:10 -0700 Subject: [PAT