View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000643 | file | General | public | 2025-04-13 19:39 | 2025-09-08 15:51 |
| Reporter | tomh | Assigned To | christos | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Platform | x86_64 | OS | Fedora | OS Version | 42 |
| Product Version | 5.46 | ||||
| Summary | 0000643: file -z tries and fails to decompress zip files | ||||
| Description | This is a regression in file 5.46 relative to 5.45 where it tries, and fails to decompress the file when -z is used and then fails to report a type. | ||||
| Steps To Reproduce | Using the attached file, which is actually a zip file: % file f.gpx f.gpx: Zip archive data, made by v3.0 UNIX, extract using at least v2.0, last modified, last modified Sun, Jul 26 2018 17:45:04, uncompressed size 701, method=deflate % file -z g.gpx f.gpx: ERROR:[gzip: Stdin has more than one entry--rest ignored] (data) | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
I don't see much difference between 5.45 an 5.46 (they both fail to decompress as expected) [8:34am] 106>./file -m ../magic/magic.mgc ~/f.gfx /u/christos/f.gfx: Zip archive data, made by v3.0 UNIX, extract using at least v2.0, last modified Jul 26 2018 17:45:04, uncompressed size 701, method=deflate [8:34am] 107>/usr/bin/file ~/f.gfx /u/christos/f.gfx: Zip archive data, at least v2.0 to extract, compression method=deflate [8:35am] 108>./file -z -m ../magic/magic.mgc ~/f.gfx /u/christos/f.gfx: ERROR:[gzip: ] (Zip archive, with extra data prepended) [8:35am] 109>/usr/bin/file -z ~/f.gfx /u/christos/f.gfx: ERROR:[gzip: ] (Zip archive data, at least v2.0 to extract, compression method=deflate) [8:35am] 110>/usr/bin/file -v file-5.45 magic file from /usr/share/misc/magic [8:37am] 111>./file -v file-5.46 magic file from /usr/local/share/misc/magic |
|
|
After some more investigation I think I misunderstood the problem. Both do indeed report a gzip error but the difference is in the comment field after that. This is with local builds I just did: bericote [~] % /var/tmp/file-5-45/bin/file -z /tmp/f.gpx /tmp/f.gpx: ERROR:[gzip: Stdin has more than one entry--rest ignored] (Zip archive data, at least v2.0 to extract, compression method=deflate) bericote [~] % /var/tmp/file-5-46/bin/file -z /tmp/f.gpx /tmp/f.gpx: ERROR:[gzip: Stdin has more than one entry--rest ignored] (data) Note that "Zip archive data..." at the end has become "data" in the second case and the test code where I encountered it had, probably accidentally, been relying on detecting "Zip archive" in that comment recognise the file as a zip. It looks like you're not reproducing that either, which I don't really understand. Note that I had to disable seccomp in my builds or it would get killed by the sandbox in both versions - it seems the Fedora packaged versions I normally use are not enabling seccomp. |
|
|
I get it now. Your version of file does not use the gzip library code (i.e. the decompressor is not build-in to file) like it is for mine. It invokes gunzip to decompress and that decompresses the first file: [9:38am] 1006>gunzip < ~/f.gfx <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.0" creator="GPSBabel - http://www.gpsbabel.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/0" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd"> <time>2008-10-01T10:10:10.000Z</time> <bounds minlat="1.0" minlon="1.0" maxlat="1.0" maxlon="1.0"/> <trk> <trkseg> <trkpt lat="1.0" lon="1.0"> <ele>134.0</ele> <time>2008-10-01T10:10:10.000Z</time> <course>112.430000</course> <speed>0.072022</speed> <fix>3d</fix> <sat>4</sat> <hdop>2.400000</hdop> <vdop>2.600000</vdop> <pdop>3.600000</pdop> </trkpt> </trkseg> </trk> </gpx> gzip: stdin has more than one entry--rest ignored Exit 2 So the error path file gets is different and this is why it prints "data". I will try to figure out what's going on when the decompressor is not built-in. |
|
|
Actually my builds are linked against libz? bericote [~] % ldd /var/tmp/file-5-46/bin/file linux-vdso.so.1 (0x00007f9534b10000) libmagic.so.1 => /var/tmp/file-5-46/lib/libmagic.so.1 (0x00007f9534adc000) libm.so.6 => /lib64/libm.so.6 (0x00007f95349be000) libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f95348fa000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f95348c5000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f95348ae000) libz.so.1 => /lib64/libz.so.1 (0x00007f953488b000) libc.so.6 => /lib64/libc.so.6 (0x00007f9534699000) /lib64/ld-linux-x86-64.so.2 (0x00007f9534b12000) Even the Fedora packaged one is linked against libz (though not libbz2 or liblzma). |
|
|
Reproducing your setup now I get: [9:58am] 10006>src/file -m magic/magic.mgc f.gfx f.gfx: Zip archive data, made by v3.0 UNIX, extract using at least v2.0, last modified Jul 26 2018 17:45:04, uncompressed size 701, method=deflate [9:58am] 10007>src/file -z -m magic/magic.mgc f.gfx f.gfx: ERROR:[gzip: Stdin has more than one entry--rest ignored] (Zip archive, with extra data prepended) [9:58am] 10008> |
|
|
strace it and see if it exec's gzip -cd |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-04-13 19:39 | tomh | New Issue | |
| 2025-04-13 19:39 | tomh | File Added: f.gpx | |
| 2025-09-08 12:37 | christos | Assigned To | => christos |
| 2025-09-08 12:37 | christos | Status | new => assigned |
| 2025-09-08 12:38 | christos | Status | assigned => feedback |
| 2025-09-08 12:38 | christos | Note Added: 0004293 | |
| 2025-09-08 13:31 | tomh | Note Added: 0004295 | |
| 2025-09-08 13:31 | tomh | Status | feedback => assigned |
| 2025-09-08 13:42 | christos | Note Added: 0004296 | |
| 2025-09-08 13:49 | tomh | Note Added: 0004297 | |
| 2025-09-08 13:59 | christos | Note Added: 0004298 | |
| 2025-09-08 15:51 | christos | Note Added: 0004299 |
