Re: [PATCH] create: Always check for sparseness if '--hole-detection=raw'

On 3/20/24 07:36, Doug Anderson wrote: If people simply need more time to evaluate this patch then I can also step back and wait patiently. I think that's what's going on. Sergey and I are pretty busy.

Re: Add set_* functions to stat-time?

On 2024-03-17 14:03, Bruno Haible wrote: * On Linux, it's not even possible to set the birthtime of a file, if that is meant to mean the ctime (change time). birthtime is when the file was first created. You can't change it. So it differs from ctime. There's nothing 'tar -x' can do

Re: GNU tar can't preserve file immutable attribute set by "chattr +i" in Linux

On 2024-03-02 18:35, 孟 大兴 wrote: Is it possible preserve file immutable attribute set by "chattr +i" when using GNU tar in Linux? Or add this function into GNU tar? It should be possible, yes. The attributes you're talking about are inode flags (see "man ioctl_iflags"). If bsdtar has some

Re: ***UNCHECKED*** delete.c flush_file() adds file size to current_blocks w/o sanity check

nostic. The second fixes an unchecked integer overflow nearby. And the third should fix the bug you reported. Thanks again.From 21318f385627a30da5d92811dd80f70abbe80ee7 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 3 Mar 2024 13:17:32 -0800 Subject: [PATCH 1/3] tar: improve diagnostic for tru

Re: prefer local files to network connections

On 2024-01-30 11:02, Paul Eggert wrote: Perhaps it's time to evolve tar in the direction that it should have gone back in the 1980s. That is, we add an option --remote to require remote interpretation of file names, and warn if a remote file name is used without --remote. Eventually we can

Re: prefer local files to network connections

On 2024-01-30 10:57, Sam James wrote: The whole thing is bizarre and continues to catch people by surprise: https://lists.gnu.org/archive/html/bug-tar/2017-05/msg2.html. Yes, if I could go back decades in time I would say "don't implement it that way -- add an option instead!" What 'tar'

Re: prefer local files to network connections

On 2024-01-30 10:09, Sergey Poznyakoff wrote: Hi Karl! I suggest that tar check if a file exists before trying to make a network connection. This would eliminate the need for --force-local in (I expect) most cases. As in: Nice idea. I'll implement it. Wait, does this mean 'tar -cf

Re: [GNU tar 1.34] testsuite: 89 131 132 failed

| 6 +++--- 10 files changed, 51 insertions(+), 27 deletions(-) diff --git a/ChangeLog b/ChangeLog index 46c2f77242..746a1ea70f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,20 @@ +2023-12-28 Paul Eggert + + stat-time: fix macOS bug with negative file times + macOS has a bug similar (but

Re: Possible Memcpy and write out of bounds error in Wordsplit.

Thanks, I think that bug was fixed here: https://git.savannah.gnu.org/cgit/tar.git/commit/?id=5114218025b4562392dd260e2533d3fa2bc0220e

Re: Potential Null pointer dereference in tar 1.35

Could you please look at the current sources? That part of 'tar' has changed significantly since 1.35, and I don't see a bug in the latest version. If the bug's still there, please let us know. Here's how to get a copy of the current sources: git clone https://git.savannah.gnu.org/git/tar.git

Re: undefined behavior spotted in the source code of gtar

Thanks for reporting that. I installed the attached fix, which is more elaborate than what you suggested but simplifies the code and should help avoid similar problems in the future.From 78d4ccd75531ac61552a6aa97c6df7238b16cbd3 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 11 Sep 2023

Re: [PATCH] .gitmodules: switch to HTTPS

Thanks, I installed that.

Re: O(n^2) time complexity bug in Tar with incremental or `--delay-directory-restore` extractions

Thanks again for the performance improvement. As the copyright paperwork is done I installed it onto Savannah, along with attached minor followup patches.From 12b58a69aa97acf12403065fb7b4a2b6e22cd7e9 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 21 Aug 2023 13:40:37 -0700 Subject

Re: tar 1.35: --delete creates tarfiles with duplicate file paths

On 2023-08-10 08:56, Ed Santiago wrote: I've tried to git-bisect but am embarrassed to say I can't even get tar to compile from git, not with gcc 12 or 13, due to warnings being treated as fatal. Try "make WERROR_CFLAGS=".

Re: --set-mtime-command (was Re: posix atime/ctime changes despite mtime being set)

On 2023-08-02 11:09, Sergey Poznyakoff wrote: Some time ago Bruno Haible suggested a simpler approach, which may be better for GNU tar's users. Here's the idea, which requires two passes over the input files, the first to collect timestamp info: I like the idea, although I doubt that its

Re: ***UNCHECKED*** A stack overflow when extracting a tar file with a long xattr key

Sergey fixed that bug here: https://git.savannah.gnu.org/cgit/tar.git/commit/?id=a339f05cd269013fa133d2f148d73f6f7d4247e4 and the fix appears in tar 1.35, released July 18.

Re: --set-mtime-command (was Re: posix atime/ctime changes despite mtime being set)

On 2023-08-01 06:36, Sergey Poznyakoff wrote: Opinions? Thanks for looking into this. My first reaction is that it's a bit complicated and I would omit --set-mtime-format as being more trouble than it's worth, and by default disable warnings about the command issuing an empty log message.

Re: posix atime/ctime changes despite mtime being set

On 2023-07-31 10:16, Sergey Poznyakoff wrote: --set-mtime COMMAND where COMMAND is any shell command that takes a file as its argument and outputs a timestamp e.g. in seconds from the Epoch. What do you think? Sure, that sounds reasonable. We need to try it out with Git, though; it needs

Re: posix atime/ctime changes despite mtime being set

On 2023-07-31 08:29, Sergey Poznyakoff wrote: As an afterthought, this is not necessarily so, because POSIX format with all extended headers removed, is indistinguishable from ustar. Right, and if Piotr can remote the subsecond components from his timestamps, he'll be generating posix-format

Re: posix atime/ctime changes despite mtime being set

On 2023-07-31 07:54, Sergey Poznyakoff wrote: is this used in addition to --mtime --clamp-mtime options or instead of them? What I see at are differences like the following. One archive has

Re: O(n^2) time complexity bug in Tar with incremental or `--delay-directory-restore` extractions

Hasn't this performance bug already been fixed in GNU Tar, here? https://git.savannah.gnu.org/cgit/tar.git/commit/?id=258d1c44e5ee7c58b28bfe9d737df6081885 Please try GNU Tar 1.35, which has this fix. If it doesn't work for you, please let us know.

Re: posix atime/ctime changes despite mtime being set

Thanks, I installed that patch. In thinking about the recipe I noticed that it doesn't talk about directory timestamps. I installed the attached to address this issue, and also to document the recipe a bit better.From 68636f0bcb83e83041cf3198b09dbcf138b2ee69 Mon Sep 17 00:00:00 2001 From: Paul

Re: posix atime/ctime changes despite mtime being set

On 2023-07-25 05:13, Sergey Poznyakoff wrote: as you can see on this output the only differences are between timestamps e.g.: 7 -rw-r--r--···00··· 7 -rw-r--r--···00···

Re: posix atime/ctime changes despite mtime being set

a5ded865303041e3 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 24 Jul 2023 14:43:30 -0700 Subject: [PATCH] New doc about reproducible archives * doc/tar.texi (Reproducibility): New section. Spruce some other sections related to timestamps etc. --- NEWS | 9 +-

Re: exclude17.at and exclude18.at tests are missing in the tar-1.35 tarball

On 2023-07-21 01:54, Pavel Raiskup wrote: I think the problems happen because we do do `autoreconf -v` for the GNU tar package in Fedora (we have several patches applied on top of the upstream tarball). Some distributions (not Fedora) do this by default per their policies, so I would eventually

Re: exclude17.at and exclude18.at tests are missing in the tar-1.35 tarball

On 2023-07-20 12:28, Lukas Javorsky wrote: It does fail as the testsuite doesn't find those two tests. Odd, as it works for me from a fresh tarball straight from gnu.org. See attached transcript, which I ran on Ubuntu 23.04 x86-64. Perhaps the timestamps are messed up on your copy? What

Re: libintl also missing in tests/Makefile.am

Thanks, I installed that.

Re: [PATCH] tests: Fix xz tests by unsetting XZ_OPT, XZ_DEFAULTS

Thanks, I installed that too.

Re: [PATCH] tests: Fix bashism in testsuite.at

On 2023-07-18 08:45, Sam James wrote: &> is a bashism and causes various tests to fail with /bin/sh as non-bash (e.g. dash). Thanks, I installed that, with a "Copyright-paperwork-exempt: true" line in the commit message (rather than with a "Signed-off-by:" line) as per the usual Gnu rules.

Re: exclude17.at and exclude18.at tests are missing in the tar-1.35 tarball

lease process, which should catch this kind of problem.) Yes it would, thanks.From 39849e9d91f477d3fb839f93cd0815d0cb3273e9 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 18 Jul 2023 09:15:03 -0700 Subject: [PATCH] tests: fix TESTSUITE_AT Problem reported by Lukas Javorsky in: https://lists.gn

Re: Please cut a new release for modern C fixes

I'd like to get a new Autoconf release out first, so that we can use it to generate a new Tar release. Of course it shouldn't wait forever.

Re: --delete action prints "Bad file descriptor" due to insufficient privilege

On 2023-02-04 20:55, Maxim Cournoyer wrote: I used tar 1.34 as packaged in GNU Guix. I can't reproduce the problem with tar 1.34 as packaged in GNU Guix 1.4.0 (a fresh boot from the distributed x86-64 QEMU image).

Re: Tar uses the deprecated 'gethostbyname' func

On 2022-12-13 06:02, Lukas Javorsky wrote: Hi, I've been working on maintaining tar in all of our operating systems lately and one of our automated tests noticed that the tar is still using the old 'gethostbyname' function. It's common for applications that use this function to switch to

Re: tar is creating corrupt archives when soft links are present

On 2022-12-01 15:53, Dominique Martinet wrote: The fstatat64 structs returned from bin/awk and bin/bash are truncated, could you provide the same strace with '-v' ? Yes, I'd also like to see the output with strace -v. Assuming that looks good, I'd then like to see what GDB says about tar,

Re: Appending from non-seekable input like /dev/stdin silently fails

24c830696527566742f1c8cac70d53086afca599 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 3 Nov 2022 23:07:11 -0700 Subject: [PATCH] Fix -Af F bug when F is not a regular file MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by Boris Gjenero in: https

Re: Crash on malformed archive

READMEish things.From ba26ec86e2a6df7de1cb7e43b0be893b5ab68a7a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 3 Nov 2022 22:56:18 -0700 Subject: [PATCH] Fix README-* files README-alpha is for alpha releases, which are not from Git or CVS, so omit mention of that. I'm not sure we'll ever do

Re: Crash on malformed archive

Thanks for the report. Unfortunately I'm not seeing the crash here. I'm running on Ubuntu 22.10 x86-64, and built tar 1.34 from source with: ./configure make CFLAGS='-g3 -O2 -fsanitize=address' Here's my failed attempt to reproduce the bug: $ mkdir d $ cd d $ ../src/tar -G -g -S

Re: [GNU tar 1.28] testsuite: 5 6 7 8 9 12 15 20 33 40 41 42 47 57 60 63 64 65 66 68 71 73 75 76 85 87 89 90 94 failed

Looks like you're using a shell that invokes 'tar' and passes the fully-qualified file name as argv[0]. You might try using a shell that doesn't do that; 'tar' (and most other programs) expect $0 to be the name used to invoke the program.

Re: Inconsistent list output

On 9/10/22 09:51, Dr. David Alan Gilbert wrote: Why 'user/group size' and not two separate fields of 'user/group' and 'size'? Two separate fields would consume more screen space, because the first column is left-adjusted and the second column is right-adjusted. It's the same reason that

Re: Inconsistent list output

On 9/8/22 14:23, Andreas Dilger wrote: GNU "ls" has this unfortunate misfeature of reading the whole directory to read+stat every entry in a directory to determine field width before displaying anything (even if unsorted), and this is a real problem for large directories on a network

Re: Inconsistent list output

On 9/8/22 12:25, Ingo Brückl wrote: I'm talking about the Unix UserID/GroupID with a historical maximum of 8*characters* each! I see no such limit in 7th Edition Unix. The only limit I see is around 500 bytes for user and group names.

Re: Inconsistent list output

On 9/8/22 03:46, Ingo Brückl wrote: The offset seems to occur when length(u_id) + length(g_id) >= 14. Wouldn't it make sense to at least consider the possible Unix length (8-digit u_id, g_id)? Sorry, I don't know where that "8" comes from. In the original Unix, user IDs had at most 5 digits.

Re: Inconsistent list output

Since tar can't know the maximum values in each column, other than by looking at machine maximum, it'd havetomake those columns very wide to have them line up. I doubt whether that would be a win in general.

Re: 'tar --delete' destroys an archive

Thanks for reminding me about that. I installed the attached patch, which fixed things for me.From f8e14746d2ca72804a4520c059d7bf65ca00c5ac Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 2 Sep 2022 16:32:27 -0500 Subject: [PATCH] Fix --delete bug with short reads MIME-Version: 1.0 Content

Re: tar -x --xattr with read-only files

0b74885e81b90d6ab4890b195dce99ca9109fe59 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 26 Aug 2022 15:23:23 -0500 Subject: [PATCH 1/2] Fix bug with -x --xattr read-only files MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by Kevin Raymond

Re: Race condition in creating directories

On 8/25/22 07:02, Simon Lees wrote: > Thanks for the bug report. How about the attached patch instead? It's a bit more conservative than what you proposed. (I haven't tested it.) We tested the0001-Retry-file-creation-more-aggressively.patch for a customer and found it was possible to cause

Re: Quadratic performance due to symlink processing

proposition.From 258d1c44e5ee7c58b28bfe9d737df6081885 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 15 Aug 2022 00:05:53 -0700 Subject: [PATCH] Avoid quadratic behavior with delayed links MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Do

Re: [GNU tar 1.25] testsuite: 44 failed

GNU Tar 1.25 is pretty old (2010). What happens when you use the current GNU Tar 1.31, dated last year?

Re: split bootstrap in two phases, GNU tar

On 7/24/22 16:18, Bruno Haible wrote: For (a), everything works already. The old 'bootstrap' script has hardwired code to fetch gnulib/build-aux/bootstrap. This gets executed, and this intermediate, not really functional 'bootstrap' script gets copied into the package and gets executed. It

Re: split bootstrap in two phases, GNU tar

h, instead of autogen.sh, autopull.sh, bootstrap-funclib.sh, so as to keep the top level simple. Is that easy to arrange?From 5c4f8cadbd362497dc3c3136566589557ce00f1b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 24 Jul 2022 11:44:12 -0700 Subject: [PATCH] Adjust to Gnulib bootstrap revamp *

Re: Man page documentation on --xattrs-include incorrectly states that pattern is a regular expression

Thanks for reporting that. I installed the attached patch.From 496cf61638852ba20dcdec1f64027b1d9fd74539 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 11 Jul 2022 10:34:25 -0500 Subject: [PATCH] * doc/tar.1: Fix --xattrs-exclude typo. --- doc/tar.1 | 10 +- 1 file changed, 5

Re: Build failure from git HEAD

Thanks for reporting that. I installed the attached to fix it.From 9f0e54ab2fcae945eef441ebb0d217bbccc6c75b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 13 Jun 2022 16:49:55 -0700 Subject: [PATCH] =?UTF-8?q?Fix=20=E2=80=98make=20dist-xz=E2=80=99=20bug?= MIME-Version: 1.0 Content-Type

Re: Cannot get immutable to work

rom someone you don't know, you don't get files with weird attributes. At this point it might be a bit late to change the default as people are most likely depending on it.From 4eb9d052b21eea93d9030f1d34416af68a1f14f0 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 12 Jun 2022 20:33:0

Re: Race condition in creating directories

On 3/31/22 18:27, Paul Eggert wrote: Thanks for the bug report. How about the attached patch instead? It's a bit more conservative than what you proposed. (I haven't tested it.) After testing it I see that patch wasn't right and that the patch you proposed was better. However, I now see

Re: Revisiting "file changed as we read it", with a proposed patch

c1027eb5aee7b2a942c601ef6cdb1b132da83225 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 9 Jun 2022 15:50:06 -0700 Subject: [PATCH] =?UTF-8?q?Warn=20=E2=80=9Cfile=20changed=20as=20we=20read?= =?UTF-8?q?=20it=E2=80=9D=20less=20often?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer

Re: Revisiting "file changed as we read it", with a proposed patch

On 6/3/22 03:13, Piotr P. Stefaniak wrote: 2. How about a simpler option which basically says: warn only about changes to any of the following: st_mtime, st_uid, st_gid, st_mode, st_size. It's not clear that the extra complexity of a more-complicated option is worth the aggravation. This

Re: Revisiting "file changed as we read it", with a proposed patch

It sounds like something like this would be a good thing to have. A few thoughts. 1. If the mtime or size changes, doesn't this necessarily mean that ctime changes? In other words, isn't tar's current test for size growing redundant? This test was added in commit

Re: Typo in GNU tar manual 2.6.3

Thanks for reporting that. I installed the attached fix, which should appear in the next 'tar' release.From d6d104e8a66472fa1899fede0faf6ceac99cd721 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 3 May 2022 15:25:03 -0700 Subject: [PATCH] doc: fix abrupt sentence in HTML MIME-Version: 1.0

Re: bug#20453: Building on AIX 7.1 with GCC

On 4/28/15 19:25, Sevan Janiyan wrote: Just ran into an issue which affects gzip, gettext & tar on AIX. Thanks for reporting that seven years ago. I just now tried building bleeding-edge gzip and gettext 0.21 on AIX 7.1 with xlc, and it worked for me. gzip no longer uses quotearg, and

Re: Race condition in creating directories

Thanks for the bug report. How about the attached patch instead? It's a bit more conservative than what you proposed. (I haven't tested it.)From 49b9f54ff66d126c4c0d58ccfbc2b85f96f845fc Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 31 Mar 2022 18:26:03 -0700 Subject: [PATCH] Retry file

Re: Improvement of man pages of TAR

Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 15 Feb 2022 17:40:34 -0800 Subject: [PATCH] tar: revamp "file is the archive" diagnostic * src/create.c (dump_file0): For clarity, change diagnostic wording from "file is the archive; not dumped" to "archive cannot contain i

Re: Improvement of man pages of TAR

On 2/13/22 08:11, Antonio Diaz Diaz wrote: 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

Re: Bug in handling hard links in bind-mounted directories

On 1/12/22 14:50, Derek Pressnall wrote: My assumption was that this logic (to track inodes for all files if more than one file was listed) was put in place to handle cases where there may be a bind mount Actually I expect it's because if more than one file is listed then there may be

Re: [PATCH] change default --format from gnu to posix

On 12/19/21 10:29, Mike Frysinger wrote: i don't care about extensions, i care that the "gnu" format has known limitations in how it stores paths that "pax" fixes. so if you have an alternative that doesn't have these issues, and has a chance of being widely adopted like "pax", What

Re: [PATCH] change default --format from gnu to posix

On 12/13/21 22:02, Mike Frysinger wrote: LC_COLLATE=C tar \ --format=pax \ --sort=name \ --owner=0 --group=0 \ --pax-option=exthdr.name=%d/PaxHeaders/%f,atime:=0,ctime:=0 \ -cf foo.tar foo/ use of --mtime=0 is prob debatable. tzdb uses --pax-option='delete=atime,delete=ctime'

Re: [PATCH] change default --format from gnu to posix

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 --format=pax is that it gratuitously uses pax extensions when not needed by the

Re: [PATCH] change default --format from gnu to posix

On 12/13/21 12:50, Paul Eggert wrote: I installed the attached patch to suggest --pax option 'delete=[ac]time' instead; this should work around the issue. After fooling around with --format=ustar and --format=pax a bit more with tzdb, and discovering the Y2242 problem that I'd forgotten about

Re: [PATCH] change default --format from gnu to posix

software distros"...From 205ed228925b1d2c1052821b604703b1b7931089 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 13 Dec 2021 12:42:11 -0800 Subject: [PATCH] More reproducible tarball doc * doc/tar.texi (PAX keywords): Improve discussion of how to generate reproducible ta

Re: [PATCH] change default --format from gnu to posix

On 12/11/21 20:21, Mike Frysinger wrote: the warning is issued when DEFAULT_ARCHIVE_FORMAT has not been set by the builder, so the default value is used. if the builder has set a value, then no warning is shown. Sorry, I must have got the code backward when I read it. i guess i could

Re: [PATCH] change default --format from gnu to posix

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 classic chicken-and-egg problem. Something along the lines of patch 1/2 looks OK, though the

Re: [PATCH] change default --format from gnu to posix

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 to a standard format wouldn't necessarily mean that we'd switch to pax, and

Re: [PATCH] change default --format from gnu to posix

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 version for almost as long, so lets finally actually switch it. This sounds

Re: better default support for parallel compression

On 11/4/21 13:52, Mike Frysinger wrote: how are you defining "performance" ? to me, the only metric that matters is $ time tar xf I care about energy consumption too.

Re: Path Hijack vulnerability

On 11/3/21 07:21, Gregorio Giacobbe wrote: The remediation would be to make sure that tar calls gzip by its absolute path. Sure, just do this when building 'tar': ./configure --with-gzip=/usr/bin/gzip This resolves the issue. I doubt whether we should make this configure-time option the

Re: tests/time01.at failing on i586, ppc and armv7l

On 10/14/21 11:36 PM, Bernhard Voelker wrote: it seems surprising that `tar -c` succeeds, and only the later `tar -d` complains, because both supposedly do a stat(). I didn't look into the code, so I assume that -c is constraining the values silently into the valid range, doesn't it? If the

Re: buildbot failure in OpenCSW Buildbot on gtar-solaris10-i386

On 10/13/21 14:51, build...@opencsw.org wrote: The Buildbot has detected a new failure on builder gtar-solaris10-i386 while building gtar. https://buildfarm.opencsw.org/buildbot/builders/gtar-solaris10-i386/builds/169 This build fails because the Solaris 10 Buildbot has Automake 1.14.1

Re: tests/time01.at failing on i586, ppc and armv7l

On 10/13/21 13:57, Bernhard Voelker wrote: Is it possible that newer touch(1) from coreutils-9.0 supports more of the tricky timestamps which tar-1.34 still fails to grok? I guess that coreutils was built with 64-bit time_t, but the compiler or development library for some reason doesn't

Re: [PATCH] fix GCC 8 compile error

On 9/18/21 9:26 AM, Christian Schoenebeck wrote: apparently this compile error will retain in the next release tarball. It shouldn't do that. Have you tried building a tarball with 'make dist' and built from that with 'configure; make'? If that fails to build on your older platform, please

Re: [PATCH] fix GCC 8 compile error

From: Paul Eggert Date: Sat, 18 Sep 2021 08:16:04 -0700 Subject: [PATCH] build: document WERROR_CFLAGS * README-hacking: Mention 'make WERROR_CFLAGS='. --- README-hacking | 4 1 file changed, 4 insertions(+) diff --git a/README-hacking b/README-hacking index 4f6de652..0381d513 100644

Re: [PATCH] fix GCC 8 compile error

On 9/17/21 9:33 AM, Christian Schoenebeck wrote: attached patch fixes a compile error with GCC 8, whining about missing malloc function attribute. As I understand it, this patch is not needed for recent GCC, which is smart enough to not require programmers to specify attributes that GCC can

Re: tar does not support partial reads

On 7/19/21 7:54 AM, Christian Schoenebeck wrote: POSIX compliant applications must always expect that read() / write() functions might read/write less bytes than requested Although that's true in general, it's not true for regular files. The POSIX spec for 'read'

Re: tar extract errors occurring rarely but with same symptoms

On 6/5/21 10:23 PM, Daniel Villeneuve wrote: openat(AT_FDCWD, "XX_config/static/users", O_WRONLY|O_CREAT|O_EXCL, 000) = 4 fstat(4, {st_mode=S_IFREG|000, st_size=0, ...}) = 0 close(4)    = 0 OK, so at this point the newly-created file XX_config/static/users

Re: tar extract errors occurring rarely but with same symptoms

On 6/5/21 9:39 AM, Daniel Villeneuve wrote: And when a problem like the above occurs, our process tries it again and it  usually succeeds (that is, I've never witnessed two successive failures). When you say "it usually succeeds", do you mean that you extract from the exact same tarball and

Re: cpio - covscan issues

On 4/8/21 12:47 AM, Ondrej Dubaj wrote: diff --git a/src/tar.c b/src/tar.c index 99ef8a2..a5873e7 100644 --- a/src/tar.c +++ b/src/tar.c @@ -146,6 +146,7 @@ write_out_tar_header (struct cpio_file_stat *file_hdr, int out_des) name_len = strlen (file_hdr->c_name); if (name_len <=

Re: tar - covscan issues

All these GNU Tar Coverity reports appear to be false alarms. Here are some details: On 4/7/21 1:24 AM, Ondrej Dubaj wrote: - return copy != NULL ? copy : data; + if (copy != NULL) + { +data = NULL; +return copy; + } + else +return data; This

Re: [gnu.org #1697096] GNU tar online manual

On 3/1/21 10:49 AM, Sergey Poznyakoff wrote: Committed with c67d223854d7c0f457dc6c7518a04e648873b50b. See the file doc/README.manual. Thank you. Generating the manuals has always been a bit mysterious for me

Re: [gnu.org #1697096] GNU tar online manual

On 2/27/21 1:27 AM, Therese Godefroy via RT wrote: Hello Tar maintainers, I think this ticket is for you. The stylesheet is automatically included by gendocs.sh if gendocs_template is in the directory containing the Texinfo source, along with the script:

Re: Backward compatibility

On 2/26/21 6:53 AM, Stephen Boswell wrote: I have written tapes using tar 1.26 on tape server with centos-release-7-4.1708.el7.centos.x86_64 My client has tar version 1.23 and cannot extract tarball’s.  Any solution? I'm surprised, as I just now created a tar archive with tar 1.26 and

Re: gcc-10 -O2 -W{cast-align,deprecated-declarations,maybe-uninitialized,null-dereference}

On 11/22/20 3:29 AM, Janos LENART wrote: I have attached a patch that I am using now as a stop gap. Unfortunately that attachment was a binary file containing only 19 bytes.

Re: Unexpected behaviour when creating a tarball with -h: symlinks are replaced by hardlinks

On 8/12/20 2:52 PM, bug|gnu...@nanl.de wrote: However what I'm experiencing is - while -h indeed does not preserve the symlinks - it replaces them with hard links instead of actually de-referencing them and including the original file. It sounds like you want to use tar's --hard-dereference

Re: Tar doesn't handle short reads

On 8/5/20 2:58 PM, Dominique Martinet wrote: if the second read fails with EIO then at that point in the loop ret < 0 and full_read returns -1. Are you looking at the same source code I am? There is no "ret < 0" in lib/full-write.c - at least, not in my copy of GNU Tar (I'm looking at current

Re: Tar doesn't handle short reads

On 8/5/20 11:47 AM, Nikos Tsipinakis wrote: Can you elaborate? I can't find a code path that loses the errno. full_read reads a partial block and then tries to read again. The second read fails with errno == EIO. full_read then returns the number of bytes successfully read, and the caller

Re: Tar doesn't handle short reads

On 8/4/20 4:48 PM, Nikos Tsipinakis wrote: Given the hesitation to fstat in order to remove the O_NONBLOCK flag, are there any objections to applying the patches sent in the original email? i.e. re-call read until the full file has been read. Simply switching from safe_read to full_read would

Re: Tar doesn't handle short reads

On 7/29/20 1:31 AM, Dominique Martinet wrote: But we do stat before, and have that race condition already, because of the 0-blocks sparse file optimization at least ? I didn't know that, but if that's the case that's a race that should also be fixed. even if the file is regular, it can

Re: Tar doesn't handle short reads

On 7/27/20 6:33 AM, Dominique Martinet wrote: It's interesting to see an application actually does open regular files with O_NONBLOCK; when this was discussed in the pull request[2] basically the agreement was that apps should either just not be setting nonblock (which ought to be no-op on

Re: Suggestion: Remove the -z / -j parameter from tar when dealing with compression

On 6/2/20 11:09 AM, Reelix wrote: > the -z / -j parameters exists for the purpose > of decreasing the resultant file size of the created archive. The > problem is that in doing so, the compression/decompression time > increases. These days those options are used more often than not, at least in

Re: possible memory corruption bug

Thanks for the bug report. I installed the attached patch. >From 96beaacd7b2c1971c05806c82478db43ad146033 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 19 May 2020 11:52:01 -0700 Subject: [PATCH] tar: avoid read overrun MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cont

Re: [Bug-tar] Suprising behavior of extract with --xattrs

On 12/19/19 2:51 PM, Brian Murray wrote: Is the mailing list the right location for me to send these patches? Yes, bug-tar is the right location for 'tar' patches. Thanks.

Re: Configure hangs at 'checking whether getcwd handles long file names properly...'

In , Qingchuan Wang (qingcwan) wrote: It hangs when ‘./configure’, I tried 1.29, 1.31 and 1.32, all same. The ‘mkdir’ didn’t return peeking by /strace./ If mkdir did not return, that sounds like a significant bug in your kernel or

Re: [Bug-tar] tar doesn't extract original date & timestamps on cifs mounts ??

I suggest running tar under strace to see what system calls it's using, and which of them goes wrong.

  1   2   3   4   5   6   >