From Bugzilla Helper: User-Agent: Mozilla/4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) Description of problem: If you try to run the 'file -z' command on an empty file that's been gzipped, file locks up. Version-Release number of selected component (if applicable): file-3.37-5 How reproducible: Always Steps to Reproduce: 1.touch emptyfile 2.gzip emptyfile 3.file -z emptyfile.gz Actual Results: The command line didn't come back. ps shows that gzip is a zombie, but file isn't paying attention. Expected Results: It should have said: emptyfile.gz: empty (gzip compressed data, deflated, original filename, `emptyfile', last modified: Thu Aug 29 11:05:18 2002, os: Unix) Additional info: Actually, this happens with any file smaller than 73 bytes and then gzipped. dd if=/usr/share/dict/words of=hello count=1 bs=72 ; gzip hello ; file -z hello.gz
Reproduced. Only happens with -z...
Fixed in file-3.39-1: bash$ touch xxx bash$ gzip xxx bash$ file -z xxx.gz xxx.gz: data (gzip compressed data, was "xxx", from Unix) bash$ file --version file-3.39 magic file from /usr/share/magic bash$ rpm -q file file-3.39-1
Er, shouldn't it say 'xxx.gz: empty (gzip compressed data, was "xxx", from Unix)'
Probably. The bug was that "file -z" hung, however.
Created attachment 82505 [details] Reports compressed empty files as 'empty', not 'data'
I've included a patch to fix the 'xxx.gz: data (gzip compressed data, was "xxx", from Unix)' problem. It now reports 'empty', not 'data' in the case of empty files.
This bug is still present in FC4.
Bug was caused by adding '\0' to content after decompression, so content was never empty. Fixed.