[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Bug in gzip 1.4?
From: |
Wieman, Karl |
Subject: |
RE: Bug in gzip 1.4? |
Date: |
Wed, 1 Dec 2010 14:20:11 -0500 |
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.