Bug 572100 - Gzip won't read files with no extension
Gzip won't read files with no extension
Product: Fedora
Classification: Fedora
Component: gzip (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Karel Klíč
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-03-10 04:48 EST by Simon Andrews
Modified: 2013-03-03 18:00 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-10 05:09:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Simon Andrews 2010-03-10 04:48:45 EST
Description of problem:

We had a load of gzipped data in files named without an extension.  We have used gzip to open them using something like:

/bin/gunzip -c -S '' some_file

As of gzip-1.3.12-15.fc12.i686 this option has stopped working an we are getting errors saying:

gzip: invalid suffix ''

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create a gzipped file with no extension
2. Use gunzip -S '' [file] to try to uncompress it
Actual results:
gzip: invalid suffix ''

Expected results:
File is uncompressed.

Additional info:
This was working OK until last nights updates so I guess this is a regression caused between gzip-1.3.12-14.fc12.i686 and gzip-1.3.12-15.fc12.i686.

The documentation for gzip appears to have changed to introduce this change specifically (null suffixes excluded rather than allowed), but with no indication how to restore the previous behaviour if you were relying on it.
Comment 1 Karel Klíč 2010-03-10 05:05:28 EST
Hello Simon,

If you used `gunzip -c -S '' some_file`, remove `-S ''` to fix your problem. `gunzip -c some_file` works well.

Have you been using `gunzip -S '' some_file` without the -c option? 
If I try to do that, gzip asks me if I wish to overwrite the some_file, and if I say yes, the file is deleted. The result is that I do not have neither the archive, nor the uncompressed file. The data are lost.
Comment 2 Simon Andrews 2010-03-10 05:09:37 EST
Thanks for the reply and the work round.

I've actually worked around this in our code by moving to using zcat instead (which is a better solution anyhow).

I'll close this since I suppose it's not really a bug.

Note You need to log in before you can comment on or make changes to this bug.