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:egg...@cs.ucla.edu] Sent: Wednesday, December 01, 2010 2:05 PM To: Wieman, Karl Cc: 'bug-gzip@gnu.org' 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/bug-gzip@gnu.org/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 <egg...@cs.ucla.edu> 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.
