On Sun, Nov 12, 2017 at 9:53 AM, Bruno Haible <br...@clisp.org> wrote: > Hi Jim, > >> The Haiku failure is due to gzexe failing due to that system's lack of >> hard link support: >> >> + eval 'env $i in-6369 < $tmp_in > $tmp_out' >> ++ env gzexe in-6369 >> in-6369: -15.4% >> ln: failed to create hard link 'in-6369~' => 'in-6369': Operation not >> supported >> /boot/home/gzip-1.8.41-9d3bb-dirty/build/tests/../gzexe: cannot backup >> in-6369 as >> in-6369~ >> + echo FAIL: gzexe >> FAIL: gzexe >> + fail=1 > > Why does gzexe expect that hard links work? Even on Linux, some file systems > do not support hard links. > > $ dd if=/dev/zero of=vfat.img bs=1048576 count=100 > $ mkfs.vfat vfat.img > $ sudo mount -o loop vfat.img /mnt > $ cd /mnt > $ sudo bash > # tar xfz ~/gzip-1.8.41-9d3bb-dirty.tar.gz > # cd gzip-1.8.41-9d3bb-dirty > # ./configure > # make > # make check
Thanks, Bruno. Here is a proposed patch:
From ccc11a69def551d0060dbd379cd84b609b837c06 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyer...@fb.com> Date: Tue, 14 Nov 2017 19:34:46 -0800 Subject: [PATCH] gzexe: work even without the ability to make a hard link * gzexe.in: When ln -f fails to create a "~"-style backup, fall back to using cp -f. Reported by Bruno Haible in http://debbugs.gnu.org/29266 --- gzexe.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gzexe.in b/gzexe.in index 290fa1c..60e750e 100644 --- a/gzexe.in +++ b/gzexe.in @@ -213,7 +213,7 @@ EOF printf >&2 '%s\n' "$0: $tmp: cannot chmod" continue } - ln -f "$file" "$file~" || { + ln -f "$file" "$file~" 2>/dev/null || cp -f "$file" "$file~" || { res=$? printf >&2 '%s\n' "$0: cannot backup $i as $i~" continue -- 2.13.5
