Re: [Bug-tar] GNU tar 1.19 on HP-UX

H.Merijn Brand wrote: > cc -DHAVE_CONFIG_H -I. -I.. -I../lib -I../lib -I../src > -DLOCALEDIR=\"/pro/share/locale\" -Ae -O2 +Onolimit +Z -z +DD64 > -I/usr/local/ia64/include -I/usr/include/X11R6 -I/usr/contrib/X11R6/include > -c argcv.c > "../lib/string.h", line 82: error #2018: expected a ")"

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 exis

[Bug-tar] Re: AC_TYPE_LONG_LONG_INT and AC_TYPE_UNSIGNED_LONG_LONG_INT

u. Whereas the one with -1ull works. Quite explainable: 18446744073709551615ULL is 0xULL -1u is 0xU so you end up comparing 0xFFFFFFFFULL against 0xULL therefore I find it quite natural that this test fails.

[Bug-tar] Re: AC_TYPE_LONG_LONG_INT and AC_TYPE_UNSIGNED_LONG_LONG_INT

the 'fprintf-posix' test. 2007-10-22 Bruno Haible <[EMAIL PROTECTED]> * lib/stdint.in.h: Add check that intmax_t and uintmax_t have the same size. *** lib/stdint.in.h.orig2007-10-23 00:07:37.0 +0200 --- lib/stdint.in.h 2007-10-23

[Bug-tar] Re: AC_TYPE_LONG_LONG_INT and AC_TYPE_UNSIGNED_LONG_LONG_INT

Paul Eggert wrote: > > 2007-10-22 Bruno Haible <[EMAIL PROTECTED]> > > > > * m4/ulonglong.m4 (AC_TYPE_UNSIGNED_LONG_LONG_INT): Use -1ull, not > > -1u, in preprocessor expression. > > Thanks for checking that. I installed that fix into gnulib,

[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

[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_

[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_

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'

Re: [Bug-tar] getline() differences FreeBSD / GNU libc

tests getline $ cd /tmp/testdir $ ./configure CPPFLAGS=-Wall # What is the configure output regarding getline and getdelim here? $ make; make check Bruno 2010-01-31 Bruno Haible Work around getline() bug on FreeBSD 8.0. * m4/getline.m4 (gl_FUNC_GETLINE): Also test resu

Re: [Bug-tar] getline() differences FreeBSD / GNU libc

> 2010-01-31 Bruno Haible > > Work around getline() bug on FreeBSD 8.0. > * m4/getline.m4 (gl_FUNC_GETLINE): Also test result for a NULL buffer > and a non-zero size. > * tests/test-getline.c (main): Likewise. > * doc/posix-functions/getl

[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

[Bug-tar] option --portability not recognized

Hi, With tar-1.23, "tar --help" says in particular: --old-archive, --portability same as --format=v7 But these options are not recognized: $ tar cf - -C /mnt --old-archive . > /dev/null tar: --old-archive: (PROGRAM ERROR) Option should have been recognize

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

Eric Blake wrote: > > I consider this a bug for two reasons: > > > > 1) glibc systems use GNU getopt. It allows to mix command line options with > >regular arguments. The very idea of this feature is that > > PROG ARGS OPTIONS > >is equivalent to > > PROG OPTIONS ARGS > > Only w

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' f

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

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

Sergey Poznyakoff wrote: > The fact that nobody has noticed > it before seems to indicate that these two options (--old-archive, > --portability) are not needed at all. Indeed, the bug was introduced between versions 1.14 and 1.15.1, that is, 6 years ago. Bruno

[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] 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

[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: source/newest/autoconf-git/autoconf/.git/objects/a2/3101e691

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 tric

Re: [Bug-tar] Unable to build tar with PGI compilers

> > PGC-S-0040-Illegal use of symbol, security_context_t (getfilecon.c: 36) > > PGC-W-0156-Type not specified, 'int' assumed (getfilecon.c: 36) It would be good to know: 1. on which platform you are experiencing this (precise distribution and release date, and the mode in which SELinux is r

[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: 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 file

Re: split bootstrap in two phases, GNU tar

nts itself as a git submodule. This is "clean", but resurfaces the problems that 'bootstrap' / 'autopull.sh' were meant to solve, namely - to present a simple, single command that can be executed directly after 'git clone' or 'git pull', - to

Re: split bootstrap in two phases, GNU tar

ithout its companion files was left on the 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.g

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 'LIBARCHIVE

[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 à part

[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 ... shortrec.at:3

tar extraction fails on a CIFS file system, due to a symlink

Hi, This is on Linux 6.8.0, with GNU tar 1.35: $ uname -srm Linux 6.8.0-50-generic x86_64 $ tar --version tar (GNU tar) 1.35 ... The attached file foo.tar was created through $ tar cvf foo.tar foo/a_symlink_before foo/a_file foo/a_symlink_after foo/a_symlink_before foo/a_file foo/a_symlink_af

[GNU tar 1.35] testsuite: 129 failed

When the current directory is under a directory symlinked to a different volume, the testsuite fails: 129: filename normalization FAILED (incr08.at:41) How to reproduce: (The shell is /bin/bash.) $ mkdir /tmp/build $ cd $HOME $ ln -s /tmp/build devbuild $ cd devbuild $ t

gnulib changed: hash_delete -> hash_remove

Hi, In 2021, Gnulib deprecated the hash_delete function. Please use hash_remove instead: diff --git a/src/incremen.c b/src/incremen.c index a2379403..92ef9c62 100644 --- a/src/incremen.c +++ b/src/incremen.c @@ -428,7 +428,7 @@ void remove_directory (const char *caname) { struct directory *