On 8/19/21 1:43 PM, Krzysztof Żelechowski wrote:
The command { gzip b; } fails because it would compress [a] without renaming
it.
The command { gzip -k b; } would not compress [a], so there is no reason to
fail.
There is a safety reason to fail. A naive user might do this:
gzip -k b && gzip -cd b.gz >b
which would trash the hard-linked file as well.
There's a similar safety issue with symbolic links:
$ ln -s a b
$ touch a
$ gzip -k b && gzip -cd b.gz >b
gzip: b: Too many levels of symbolic links
where gzip's failure prevents the naive user from trashing the linked-to
file.
Of course one can use -f to go ahead and compress anyway.
Similar diagnostics say "file ignored" or "ignored", and that is clearer
than saying "unchanged", so I installed the attached patch.
From 4b2f69227db5739b63e22a72f6db2b13972affb5 Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Thu, 19 Aug 2021 14:26:38 -0700
Subject: [PATCH] gzip: clarify "other links" diagnostic
* gzip.c (treat_file): Instead of saying
"gzip: FOO has 1 other link -- unchanged", say
"gzip: FOO has 1 other link -- file ignored".
This is clearer when -k is also used (Bug#50097).
---
gzip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gzip.c b/gzip.c
index 0123f82..f75b614 100644
--- a/gzip.c
+++ b/gzip.c
@@ -942,10 +942,10 @@ local void treat_file(iname)
}
if (2 <= istat.st_nlink)
{
- WARN ((stderr, "%s: %s has %lu other link%c -- unchanged\n",
+ WARN ((stderr, "%s: %s has %lu other link%s -- file ignored\n",
program_name, ifname,
(unsigned long int) istat.st_nlink - 1,
- istat.st_nlink == 2 ? ' ' : 's'));
+ istat.st_nlink == 2 ? "" : "s"));
close (ifd);
return;
}
--
2.30.2
