Control: tags 1138991 confirmed upstream Rene Engelhard wrote...
> While I still tihnk it shouzld take .zip as what it is, file is wrong > here. And since I didn't see a bug filed by the strip-determinism people > I am doing that right now. I at least didn't see one, forgive me if I > oversaw it. No worries. > This file was correctly detected before (see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1138710#71) as > > images_helpimg.zip: Zip archive data, made by v2.0 UNIX, extract > using at least v2.0, last modified Jun 01 2026 21:34:46, uncompressed size > 1810, method=store > > with file 5.47 I get > > images_helpimg.zip: Microsoft OOXML This is a regression introduced in upstream commit | https://github.com/file/file/commit/FILE5_46-106-g8cef37b5 | commit 8cef37b568008dceaae5b6ac1ee37827310da394 | Author: Christos Zoulas <[email protected]> | Date: Thu May 29 15:03:04 2025 +0000 | | PR/0644: omajid: Recognize NuGet packages in an attempt to detect nuget, yet another file format using .zip as a container, and that obviously has some side effects. The way file(1) tries to identfy what's inside a .zip file is a big mess, I prefer to not explain this here in detail. still I'll check whether something can be done about this. About the # that brought you here: Did I understand correctly strip-nondeterminism adjusts the timestamps in the file listing of a simple .zip file - but not if it's OOXML? Then aligning that might be a way out of your current problem. Of course, file(1) still needs to improve here. Christoph
signature.asc
Description: PGP signature
