RE: Bug in gzip 1.4?

[Wieman, Karl]

Paul,

Thanks for responding.

We have automated clean up processes that use gfind and gzip files matching 
certain criteria.  To date the criteria have not excluded files already with a 
'.gz' extension.  We use the '-f' flag since if we are zipping FILE we want it 
to automatically overwrite any existing FILE.gz, even when run interactively. 
We had been using gzip 1.3.3.  It would not do anything to files that were 
already zipped.  When we upgraded to 1.4, we started seeing files like 
FILE.gz.gz.gz.gz.gz since our automated process runs every day and every day it 
would reprocess the .gz file and gzip it again (in most cases actually making 
it bigger in the process).

We can, of course, change our processes to exclude .gz files from processing 
but I think the original behavior was correct.  I would have prefferred that 
the fix to the previous bug was implemented as a separate flag rather than 
"enhancing" the already existing '-f' functionality.  I also think the '-h' 
description of '--force' does not imply the new behavior.  Especially since 
it's unchanged since 1.3.3.

Thanks,

-Karl Wieman

-----Original Message-----
From: Paul Eggert [mailto:address@hidden 
Sent: Wednesday, December 01, 2010 2:05 PM
To: Wieman, Karl
Cc: 'address@hidden'
Subject: Re: Bug in gzip 1.4?

On 12/01/10 04:41, Wieman, Karl wrote:

> Under gzip 1.4, if you specify --force, gzip will attempt to
> compress 'FILE.gz' and create 'FILE.gz.gz'.  Under previous
> versions, even with '-f' specified, it would exit with "gzip:
> FILE.gz already has .gz suffix -- unchanged" and leave FILE.gz
> unchanged.

This change predates 1.4: it was in gzip 1.3.13 (dated 2009-09-30).
It was installed due to an earlier bug report; see
<http://www.mail-archive.com/address@hidden/msg00091.html>.

> We use -f to allow gzip to overwrite existing .gz files without prompting.

Sorry, I don't get the connection.  -f still does that:

   $ echo foo >foo
   $ gzip foo
   $ echo blahblah >foo
   $ ls -l foo*
   -rw-r--r-- 1 eggert eggert  9 Dec  1 10:55 foo
   -rw-r--r-- 1 eggert eggert 28 Dec  1 10:55 foo.gz
   $ gzip -f foo
   $ ls -l foo*
   -rw-r--r-- 1 eggert eggert 31 Dec  1 10:55 foo.gz

Can you please give a useful scenario that used to work under gzip
1.3.12 but fails in later gzips?

Hmm, I see that NEWS incorrectly claimed that this change was in
gzip 1.3.12.  I fixed this as follows:

>From 8290fee360b58995c6b58404817afcc032c3473e Mon Sep 17 00:00:00 2001
From: Paul Eggert <address@hidden>
Date: Wed, 1 Dec 2010 11:02:04 -0800
Subject: [PATCH] * NEWS: The "gzip -f foo.gz" change occurred in 1.3.13, not 
1.3.12

---
 NEWS |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index 0866500..18baee4 100644
--- a/NEWS
+++ b/NEWS
@@ -52,6 +52,8 @@ GNU gzip NEWS                                    -*- outline 
-*-
 
 * Noteworthy changes in release 1.3.13 (2009-09-30) [stable]
 
+** 'gzip -f foo.gz' now creates a file foo.gz.gz instead of complaining.
+
 ** Bug fixes
 
   gzip -d no longer fails with "-" as 2nd or subsequent argument
@@ -65,8 +67,6 @@ Major changes in Gzip 1.3.12 (2007-04-13)
 
 * znew now uses $TMPDIR (default /tmp) instead of always using /tmp.
 
-* 'gzip -f foo.gz' now creates a file foo.gz.gz instead of complaining.
-
 * It is now documented that gzip ignores case when examining file name
   extensions; for example, 'gzip test.Gz' (without -f) fails because
   the file name ends in '.Gz'.
-- 
1.7.2



THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, BlackRock, Inc. and its 
subsidiaries, ("BlackRock") does not waive any confidentiality or privilege.  
If you are not the intended recipient, please notify us immediately and destroy 
the message without disclosing its contents to anyone.  Any distribution, use 
or copying of this e-mail or the information it contains by other than an 
intended recipient is unauthorized.  The views and opinions expressed in this 
e-mail message are the author's own and may not reflect the views and opinions 
of BlackRock, unless the author is authorized by BlackRock to express such 
views or opinions on its behalf.  All email sent to or from this address is 
subject to electronic storage and review by BlackRock.  Although BlackRock 
operates anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.