Missing SHA-256 Value
Started by Kyall
avatar
Kyall Rep. 477
#1   02 Sep 2024
Hey @Tig, I noticed on the download section for Villain's Village by {STD}General that the SHA-256 value is showing as currently unknown. I'm not sure if this is something specific to this map or a site related issue, but I thought I should mention it to you anyway.

P.S. There's a minor typo in the preview message when creating a new thread (remember is missing a letter) :)

avatar
Tig Rep. 2272
#2   02 Sep 2024
@Kyall : Thanks! The missing sha256 value is an interesting case. The problem is related to the incorrect structure of the zip file and the PK3 within the zip. Basically, most of the files are being defined as a directory. Might be able to fix this, but will take a little bit of time. This map is missing from LiveView for the same reason.

The typo has been fixed as well. Thanks for taking the time to report these issues!

Update: There were 21 downloads with this issue. 20 have been fixed with minor adjustments to the script.

The last file was using compression method 9 or DEFLATE64, which is a proprietary algorithm (non-open source method). As everything I use is open source, this was causing a bit of a headache. The only option I had was to get a sha256 for the zip and manually update the database :(

avatar
Kyall Rep. 477
#3   04 Sep 2024
@Tig: Ah, that is interesting, what should they have been recognised as? Is this an issue with how some authors have packed their maps, or more to do with how they get verified for ..::LvL? And no problem, I'm glad it was of help :)
avatar
Tig Rep. 2272
#4   04 Sep 2024
@Kyall : In the originally reported map - genvv - within the pk3, the individual files have been stored as "directory" instead of "file". The Q3A engine does not care about this and if you unpack the zip your operating system reads the contents, not what the zip library stores the file as.

All the other downloads with the missing sha256 value had similar issues. Errors in the zip file that are only really visible when reading the zip structure.

The ..::LvL script reads the contents of the zip and trusted it. That is where the problem was. A few added checks and a bit of restructuring of the script and the sha256 issue is resolved. Making these maps work with LiveView will take a lot more time and checking.

As to how this has happened (incorrect data structure within the zip or pk3 files), it appears to be mostly related to poorly written zip programs.

The short answer: Not really a map author issue, more an issue with the authors choice compression programs.

avatar
Kyall Rep. 477
#5   13 Sep 2024
@Tig: Ah I see, thanks for explaining it to me. Do you think this is something that map authors might run into with compression programs that are available nowadays, or were most of the affected maps older ones? I'm just wondering if some suggestions for recommended compression programs would be helpful on the "How to submit a map" section of ..::LvL.

P.S. I spotted another minor typo whilst checking a member's stats page (in Nth for downloads, 213th was spelt as 213rd) :)

avatar
Tig Rep. 2272
#6   30 days ago
@Kyall : Nice pick-up on the ordinal issue (number suffix). Resolved now.

Please feel more than welcome to keep the corrections coming.

Only registered members can post a reply.
Already registered? Sign in.

unitooldm4
Clear