--- Begin Message ---
|
Subject: |
gzip-1.8.41 test results: help-version |
|
Date: |
Sun, 12 Nov 2017 00:39:18 +0100 |
|
User-agent: |
KMail/5.1.3 (Linux/4.4.0-98-generic; KDE/5.18.0; x86_64; ; ) |
Test results of gzip git of today + gnulib git of today (only 32-bit platforms):
On
FreeBSD/i386:
Haiku/i386:
HP-UX/hppa:
HP-UX/ia64:
FAIL: help-version
Find attached the test-suite.log of each platform.
test-suite.freebsd-i386
Description: Text document
test-suite.haiku-i386
Description: Text document
test-suite.hpux-ia64
Description: Text document
test-suite.hpux-hppa
Description: Text document
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#29266: gzip-1.8.41 test results: help-version and hard links |
|
Date: |
Thu, 16 Nov 2017 07:18:32 -0800 |
On Thu, Nov 16, 2017 at 2:37 AM, Bruno Haible <address@hidden> wrote:
> Paul Eggert wrote:
>> > + ln -f "$file" "$file~" 2>/dev/null || cp -f "$file" "$file~" || {
>>
>> This will be problematic if the destination already exists, as the
>> resulting permissions etc. may not be what the user intend. How about if
>> we fall back on "mv -f" instead? Although this has the disadvantage of
>> having a small window where "$file" does not exist, I think that's
>> preferable to the disadvantage of using "cp".
>
> How about
>
> ln -f "$file" "$file~" 2>/dev/null || { rm -f "$file~" && cp "$file"
> "$file~"; } || {
>
> then? It fixes the problem "if the destination already exists", and does
> NOT leave a window where "$file" does not exist.
Which is more important? (tempered with qualification that it probably
doesn't matter at all, since this is in the context of running a
program (gzexe) that is used very rarely, and even less frequently in
a context where ln fails to create a hard link):
- preserving backup file metadata (that backup may end up being the
sole copy of the original)
- ensuring that the specified name does not go missing briefly
Given that the backup file may be the only remaining copy of the
original, I prefer the risk of an ephemeral ENOENT, so that we can
guarantee the running of gzexe does not destroy any file metadata.
--- End Message ---