Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Gzip won't read files with no extension|
|Product:||[Fedora] Fedora||Reporter:||Simon Andrews <simon.andrews>|
|Component:||gzip||Assignee:||Karel Klíč <kklic>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||12||CC:||kklic, pertusus, rvokal|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-03-10 05:09:37 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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): gzip-1.3.12-15.fc12.i686 How reproducible: Always 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.