Subject: bug#29266: closed (Re: bug#29266: gzip-1.8.41 test results: help-version and hard links)

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 16 Nov 2017 15:19:02 +0000

Your bug report

#29266: gzip-1.8.41 test results: help-version

which was filed against the gzip package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
29266: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29266
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#29266: gzip-1.8.41 test results: help-version and hard links
From: Jim Meyering <[email-masked]>
To: Bruno Haible <[email-masked]>
Cc: [email-masked], Paul Eggert <[email-masked]>
Date: Thu, 16 Nov 2017 07:18:32 -0800
List-Id: <debbugs-submit.debbugs.gnu.org>

On Thu, Nov 16, 2017 at 2:37 AM, Bruno Haible <[email-masked]> 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.

Subject: gzip-1.8.41 test results: help-version
From: Bruno Haible <[email-masked]>
To: [email-masked]
Date: Sun, 12 Nov 2017 00:39:18 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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.