bug-gzip
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29266: gzip-1.8.41 test results: help-version and hard links


From: Jim Meyering
Subject: 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]