Subject: bug#50097: gzip: add "--keep" option to keep original files unchanged

From: Krzysztof Żelechowski <[email-masked]>
Date: Fri, 20 Aug 2021 16:52:50 +0200

Dnia piątek, 20 sierpnia 2021 16:42:54 CEST Paul Eggert pisze:
> On 8/20/21 5:20 AM, Krzysztof Żelechowski wrote:
> >> gzip -k b && gzip -cd b.gz >b
> >> 
> >> which would trash the hard-linked file as well.
> > 
> > That would replace the content of the file b with the content of the file
> > b. How bad can that be? ;-)
> 
> It could be a problem as-is if some other file reads 'a' in the middle
> of the process. And the problem would be more serious in other examples,
> such as:
> 
> echo hello >a
> ln a b
> gzip -k b && gzip -cd b.gz >>b
> 
> This would trash 'a' if gzip -k succeeded. (Same with 'ln -s'.)

The appending redirection operator has nothing to do with gzip.  It is a shell 
feature. If you need to protect dumb users from themselves, you need to design 
and implement { sh -o noclobberlinks; }.

> 
> >> > Of course one can use -f to go ahead and compress anyway.
> > 
> > That would silently replace an existing target, which is bad.
> 
> Sure. The only question here is what things "gzip -k" should be able to
> do, without the things being considered "bad".
> 
> Perhaps if you gave us the surrounding context; that might help explain
> why it would be useful to change the behavior of gzip -k on links. Bug
> report 50097 seems to start up in the middle of a conversation that I'm
> not privy to.

My normal usage of (hard) links is as follows:
Create a file page.txt. Link it to page.html.
Want to view? Open page.html.
Want to edit? Open page.txt.
Want to attach? gzip -k page.html … oops.

See ya,
Chris