Red Hat Bugzilla – Bug 72986
file command hangs on empty gzipped files
Last modified: 2007-04-18 12:46:10 EDT
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):
Steps to Reproduce:
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)
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
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
magic file from /usr/share/magic
bash$ rpm -q file
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.