Krishty

Yes. Please read again the 9th post in this thread: https://sourceforge.net/p/sevenzip/discussion/45798/thread/af29512ebd/?limit=25#9971

Yes. Please read again the 4th post in this thread: https://sourceforge.net/p/sevenzip/discussion/45798/thread/af29512ebd/?limit=25#4f2a/27bc/87a8

Understood. What says the specification on this? Is my file legal? I just quickly seached and could only find 4.4.17 file name: (Variable) 4.4.17.1 The name of the file, with optional relative path. relative path sounds to me like it’s legal to specify a directory there …

The ZIP contains only two files and the directory has been encoded into the name of the 2nd file to save the separate directory entry? Do I understand correctly?

I just created a minimal repro; it probably has to do with directories inside ZIP files. 1. 7z t -scrcsha256 broken_checksum.zip * yields data+names checksum 60A1C767B08D6AD3FA58B42FDC981681FF0006250F53CC2B1A72DD748F6F2422 2. same in GUI: Open with 7zfm, select content, compute SHA-256 3. extract anywhere 4. 7z h -scrcsha256 broken_checksum\* yields data+names checksum 6B9F30F3D39F3A5F8EC96CDF5A68EE06D05309A15BD4A3381A7BB422EEA08D19 even though names+data are identical I’ll leave this here in case...

Just noticed that it does not work on some ZIP files of mine. While the SHA-256 of extracted and compressed data is identical, the SHA-256 of data+names is different. When I extract the ZIP and hash instead of test, data+names gives the correct answer again. Maybe ZIP internally does strange things to file names. I don’t have time to investigate, sadly. For now, I’ll settle with extract + hash + delete instead of using test in-archive … Igor, I can send you the ZIP if you’re interested in the problem...

I understand – if you check a specific file, then you know the name of that file already, since you specified it on the command line, so there is no point in checking its name as well. Except when you used wildcards :-( I’d love if wildcards always printed data+names, but I understand that my use case is probably not so common. I’ll see how I can work around it. Thanks a lot for the help and – of course – for the great software, Igor!

Oh, it’s test instead of hash, sure! Stupid me! Thanks a lot, Igor. I have another problem now: I get a checksum for data+names testing multiple archived files via wildcard *, and that’s exactly what I want. 7z t archive_with_many_files.7z * -scrcsha256 SHA256 for data: EEBD07EF8322B3ACC55D0B35C148F2233C1E98080CAE6B979D2EF10F509CFBF0 SHA256 for data and names: EBA7BB637BA8817BA59D2C7991EB4ECBFE14CA1C2CD7A106501971FDEE219CE0 But if the archive contains just one file, I only get a data checksum: 7z...