[Top][All Lists]

[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: Paul Eggert
Subject: bug#29266: gzip-1.8.41 test results: help-version and hard links
Date: Thu, 16 Nov 2017 09:09:00 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 11/16/2017 07:18 AM, Jim Meyering wrote:
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):

Yes, you're right, this is bikeshedding on wheels.

  - 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.

That was basically the same analysis I used.

I tried to get fancier by using mv to rename the backup file to a "backup backup" file, but even that has problems. My guess is that if we don't have hard links we're going to have problems no matter what, so we might as well have the simplest problems we can for this rarely-used program, and "mv -f" ended up with the easiest-to-explain problem that I could think of.

reply via email to

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