Re: Add set_* functions to stat-time?

[Redirecting to bug-tar.] Collin Funk wrote in : > $ tar -xf eclipse-inst-jre-linux64.tar.gz > gtar: Ignoring unknown extended header keyword 'LIBARCHIVE.creationtime' > gtar: Ignoring unknown extended header keyword

Re: split bootstrap in two phases, GNU tar

he disk. And that is what caused the further errors and need for manual intervention. This patch fixes it. 2022-07-25 Bruno Haible bootstrap: Make the automatic sync more resilient. Reported by Paul Eggert in <https://lists.gnu.org/archive/html/bug-gnulib/2022-07/m

Re: split bootstrap in two phases, GNU tar

to solve, namely - to present a simple, single command that can be executed directly after 'git clone' or 'git pull', - to hide the complexities of 'git submodule' from the user. (I have read about submodules several times over the last few years, and still find that they are a usability

Re: split bootstrap in two phases, GNU tar

Hi dear GNU tar developers (Sergey et al.), The 'bootstrap' script from Gnulib has been reorganized to work in two phases: (1) Fetch auxiliary files that are not in the git checkout. This is the part that requires network access and that has supply-chain concerns. (2) Generate

[Bug-tar] build failure on Android

Hi, Building GNU tar (newest sources from git, with newest gnulib) on Android 4.3 fails: CC wordsplit.o ../../lib/wordsplit.c:29:18: error: glob.h: No such file or directory ../../lib/wordsplit.c: In function 'wordsplit_pathexpand': ../../lib/wordsplit.c:1807: error: 'glob_t' undeclared

Re: [Bug-tar] file changed as we read it on MacOS X

Paul Eggert wrote: On 12/23/11 22:57, Bruno Haible wrote: * It is possible that the MacOS X Spotlight indexer daemon and the MacOS X Time Machine incremental backup were running at the same time. Some programs like that play a trick: they save st_atime, then read a file

[Bug-tar] file changed as we read it on MacOS X

Hi, On MacOS X 10.5.8, with GNU tar 1.15.1, I'm seeing spurious file changed as we read it messages. $ tar cf - * | (cd /Volumes/ExtData\ 1 tar xf -) tar: source/gnu/coreutils/coreutils-8.10.tar.gz: file changed as we read it tar:

Re: [Bug-tar] Problem with fstatat on AIX 7.1

Hi Paul, Return code on that as compiled comes back as 1 . OK, thanks, to move forward on that part, I installed the following patch into gnulib. ... check for the AIX 7.1 bug But there is no AIX 7.1 bug. If fstatat would return wrong st_size fields, the return code would have been 3, not

[Bug-tar] [GNU tar 1.26] testsuite: 96 failed

Hi, After I built GNU tar 1.26 with the TAPE environment variable set, make check fails: 96: storing long sparse file names FAILED (sparse04.at:35) Details: $ echo $TAPE /dev/fd0 $ ./configure --host=i686-pc-linux-gnu --prefix=/arch/x86-linux/gnu CC=gcc -m32 -march=i586

Re: [Bug-tar] option -C ignored when it comes after the source directory

Sergey Poznyakoff wrote: It does not ignore it. It is simply useless in this form (with no arguments following it). The -C option affects all other options and arguments that follow it, up to the next -C option or end of command line, whichever occurs first. This is important for certain tar

[Bug-tar] option -C ignored when it comes after the source directory

Hi, Seen with tar-1.23 on a glibc system: $ tar cf - . -C /mnt has a different effect than $ tar cf - -C /mnt . How to reproduce: $ cd $HOME $ tar cvf - . -C /mnt /dev/null [lists the files of your home directory] $ tar cvf - -C /mnt . /dev/null [lists the files under /mnt] I

Re: [Bug-tar] option --portability not recognized

Eric Blake wrote: You meant: $ tar -cf - -C /mnt --old-archive . /dev/null No, this form of invocation yields the same error: $ tar -cf - -C /mnt --old-archive . /dev/null tar: --old-archive: (PROGRAM ERROR) Option should have been recognized!? Try `tar --help' or `tar --usage' for

Re: [Bug-tar] Wildcards do not match invalid characters

Sergey Poznyakoff wrote: ... fnmatch() indeed returns -1, which means an error happened and perror() says Invalid or incomplete multibyte or wide character. ... Thanks for reporting. I am not sure what exclude_fnmatch is supposed to return on error, since it returns bool, so I'm CC-ing

[Bug-tar] Re: AC_TYPE_LONG_LONG_INT and AC_TYPE_UNSIGNED_LONG_LONG_INT

Paul Eggert wrote: 2007-10-26 Bruno Haible [EMAIL PROTECTED] * lib/autoconf/types.m4 (_AC_TYPE_LONG_LONG_SNIPPET): New macro, extracted from AC_TYPE_LONG_LONG_INT and AC_TYPE_UNSIGNED_LONG_LONG_INT. (AC_TYPE_LONG_LONG_INT, AC_TYPE_UNSIGNED_LONG_LONG_INT): Use

[Bug-tar] Re: AC_TYPE_LONG_LONG_INT and AC_TYPE_UNSIGNED_LONG_LONG_INT

Hi Paul, On Wednesday, I proposed a patch to disable both 'unsigned long long int' and 'long long int' on Sun C 5.[0-8] in 32-bit mode, instead of only one of them. 2007-10-24 Bruno Haible [EMAIL PROTECTED] * m4/longlong.m4 (_AC_TYPE_LONG_LONG_SNIPPET): New macro, extracted

[Bug-tar] Re: AC_TYPE_LONG_LONG_INT and AC_TYPE_UNSIGNED_LONG_LONG_INT

Paul Eggert wrote: Bruno Haible [EMAIL PROTECTED] writes: #if ! (-2147483648LL 0) ... #if ! (-9223372036854775807LL 0) If a compiler can't handle that sort of line, then its bugs are more serious, since it's relatively common to do preprocessor checks like #if LLONG_MIN LONG_MIN

[Bug-tar] Re: AC_TYPE_LONG_LONG_INT and AC_TYPE_UNSIGNED_LONG_LONG_INT

0xULL therefore I find it quite natural that this test fails. I propose this fix (in gnulib, similarly for autoconf): 2007-10-22 Bruno Haible [EMAIL PROTECTED] * m4/ulonglong.m4 (AC_TYPE_UNSIGNED_LONG_LONG_INT): Use -1ull, not -1u, in preprocessor expression. --- m4

AC_TYPE_LONG_LONG_INT and AC_TYPE_UNSIGNED_LONG_LONG_INT (was: Re: [Bug-tar] GNU tar 1.19 on HP-UX)

Hi Paul, Paul Eggert wrote on 2007-10-16: Thanks for verifying this. I have started by installing the following fix to Autoconf, and will follow up on gnulib shortly. 2007-10-16 Paul Eggert [EMAIL PROTECTED] Check for 64-bit int errors in HP-UX 10.20 preprocessor. It exists also

[Bug-tar] [GNU tar 1.15.91] testsuite: 45 failed

Hi, tar 1.15.91 make check fails for me, on Linux/x86. (I reported the same failure already for tar-1.15.90 on 2006-03-03.) Relevant excerpt from testsuite.log: ## -- ## ## Detailed failed tests. ## ## -- ## 45. shortrec.at:25: testing ...

[Bug-tar] [GNU tar 1.15.90] testsuite: 35 failed

Building tar-1.15.90 failed like this. Apparently because I have the environment variable TAPE set to /dev/fd0, the floppy disk device, containing no diskette. System: $ uname -a Linux linuix 2.4.21-99-default #1 Wed Sep 24 13:30:51 UTC 2003 i686 GNU/Linux $ gcc -v Lecture des spécification à