-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OverflowError: can't convert negative int to unsigned #134
Comments
This is an extreamly interesting issue describing a case which should be impossible. Let's look at the following Python code: stringTable = '\x00'.join(file['name'] for file in self.files)
headerSize = 0x10 + len(self.files) * 0x18 + len(stringTable)
remainder = 0x10 - headerSize % 0x10
headerSize += remainder
(...)
for f in self.files:
h += (f['offset'] - headerSize).to_bytes(8, byteorder='little') First we calculate the stringTable by joining all filenames together separated by a Null character. The only way Maybe the tool which packed your game to PFS0 forgot padding the stringTable to the next 16 byte block? Actually we should be padding to the next 32 byte block according to https://wiki.oatmealdome.me/PFS0_(File_Format) but not sure if correct as everyone seams to be padding to the next 16 byte block. This issue also reminds me of your "Decompressed NSP checksum mismatch" issue as there we also had an PFS0 file where the offset of the first file was 0 instead of headerSize. I wounder why this issue didn't occur there and why the PFS0 header hash was unable to detect a missmatch as the FileEntryTable is clearly part of the PFS0 header hash. I just updated the --info command on latest master to include headerSize and the offset of every file. Could you please check out latest master and poste the result of --info on this file? Please censure/remove all sensitive information like "titleKey", "titleKeyDec" and all "key Block" before posting or better PM me the result on GBAtemp or "nicobosshard" on Discord. Please also redo the --info output of the original and broken NSP file from your "Decompressed NSP checksum mismatch" issue with the latest master so I can collect more information regarding your other issue as well. |
I also am getting this error message, although the rest of the text seems to be different. I didn't want to create a new issue if this is the same problem, so forgive me if this actually ends up being a different problem. I know nothing about programming. Here is what NSZ.exe says before outputting an invalid nsz file: ``Solid compressing (level 0) M:\PATH -> M:\PATH.nsz nut exception: [WinError 32] The process cannot access the file because it is being used by another process: "M:\PATH.nsz" During handling of the above exception, another exception occurred: Traceback (most recent call last): Compressing 100%|████████████████████████████████████████████████████████████████████| 0/0 MiB [00:00<00:00, 0.00 MiB/s] h += (f['offset'] - headerSize).to_bytes(8, byteorder='little')ackages\nsz\Fs\Pfs0.py", line 90, in getHeader Compressing 100%|████████████████████████████████████████████████████████████████████| 0/0 MiB [01:34<00:00, 0.00 MiB/s]`` Also I know it says that the file is being used by another process. It's definitely not, though. |
@swiblet Thanks a lot for reporting your findings. This is indeed the same issue. I unfortunately still haven't found what causes this. To help me investigate this issue it would be awesome if you could provide some more information. To do so either run latest master from source or get the latest portable Windows release and replace BaseFs.py with https://raw.githubusercontent.com/nicoboss/nsz/master/nsz/Fs/BaseFs.py and File.py with https://raw.githubusercontent.com/nicoboss/nsz/master/nsz/Fs/File.py. Then execute --info on your file or press the "Info" button if you use the GUI. Please censure/remove all sensitive information like "titleKey", "titleKeyDec" and all "key Block" entries before posting or PM me the result on GBAtemp (nicoboss) or Discord (nicobosshard). |
|
|
Your headerSize is 266 and the offset of the first file is on 266 as well. Let's do the calculation to see if this PFS0 header matches the standard: We have 16 bytes for the PFS0 header prior to the FileEntryTable. We then add the size of the FileEntryTable by multiplying the number of files by 24 bytes which in this case is 4 * 24 => 72 So we know that the With this we proofed that whatever tool created this NSP file did not follow the PFS0 standard as documented on https://wiki.oatmealdome.me/index.php?title=PFS0_(File_Format) in 2018. There unfortunately is no documentation about this padding inside https://switchbrew.org/w/index.php?title=NCA to verify if it must be there and if it is supposed to 0x20 or 0x10 big. We are making it us too easy by just not supporting what could be considered invalid NSP files. As long most applications see them as valid we should support them. We however need to keep in mind that bit-identical recreation means that we also have to recreate this missing padding. This can luckily easily be done. I implemented a potential fix for this issue inside #135. @nitro322, @thatch or @wsteel Could anyone of you please test the latest commit on the removal-of-string-table-padding branch and let me know if this fixes your issue? If it does please hash the file before compression and after decompression to make sure they are still bit-identical recreated. If it doesn't work please post an --info while being on the removal-of-string-table-padding branch. Thank you so much for your help investigating this issue. |
I checked the two files.
the second one works prefect, and all files hash are correct. |
Very sorry for the delay, I'll do this right now! |
Alright, so after downloading the newest release (the same one I used before) and replacing those two files you linked me, I tested with like 10 NSP's and they all compressed perfectly. Previously, like 9 out of 10 of them were having the error I posted above. I'm not sure if those files were updated with a fix, but if they were, I'd say it worked! |
The odds that I was testing this as you release 4.4.0 hahaha |
I can personally confirm, it has fixed it in my case. |
Out of town right now, but should be able to test early next week. Thanks a bunch for looking into this.
…On August 5, 2023 6:27:12 AM CDT, Nico Bosshard ***@***.***> wrote:
@nitro322, @swiblet, @wsteel This issue should be fixed in the latest [NSZ 4.4.0](https://github.com/nicoboss/nsz/releases) release. Can you please test and confirm that this issue got fixed in the latest release?
--
Reply to this email directly or view it on GitHub:
#134 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
NSZ compression works on one of the problematic NSPs from my original report. I can't find/remember which other NSP failed to compress, so assuming that one would work as well. Thumbs up here. Thanks for fixing! Just as an FYI, I still have that problem reported here with a couple NSPs failing to decompress back to the original checksum. The NSP that failed to compress for this issue is now a third suffering from that issue. I know you didn't report it fixed, but just wanted to test to confirm. Would it be helpful to create a separate bug report for that? |
@rlaphoenix @nitro322 Thanks a lot for testing. I'm really glad this fix worked. @nitro322 Oh sorry. I only looked at the PFS0 header diff between original and decompressed NSP so far and realized that there were extremely strange values for the PFS0 file offsets. From the 26 bytes that where different almost all where related to file offsets and increased by 0x10. I then got stuck as I thought I lack any further information as I didn't encounter any such case in any of my own dumps. Likely because this issue can't occur for games dumped using nxdumptool. However, I just realized that you provided much more information which I completely missed. I was now able to finally recreate your issue for the first time and can confirm its existence. Feel free to create separate issue regarding those rare cases where bit-identical PFS0 recreation fails if you want. I will give my best to fix this issue during the next weekend and do another release once this is fixed. |
I've encountered this issue with two NSPs using version 4.3:
That's obviously with block compression, but get the same error with the default solid compression. This has occurred in 2 of the 371 NSPs I've tried compressing with NSZ v4.3. One NSP is a game title, the other DLC. Both install successfully via goldleaf, so they seem to be fine, but don't know any other good way to test and verify them.
The text was updated successfully, but these errors were encountered: