Trying to view files inside ASAR with Total7zip results in "Disk read error!"

[iG0R]

Hello.
I have the Total7zip wcx-plugin with Asar7z for 7-Zip archiver https://www.tc4shell.com/en/7zip/asar/
When I enter or unpacking any asar-achive with its help everything goes fine, but if I want to view files inside (F3), it results in "Disk read error!"
TotalCommander is running with administrator privileges.
Any thoughts as to why this is happening?

[Dalai]

Can you provide a (small) sample archive?

Can you test/verify the archive in 7-zip itself without any errors? It's possible that the CRC issue mentioned here https://github.com/electron/asar/issues/110#issuecomment-1815836413 has something to do with the inability to extract files. 7-zip itself can't test/verify or properly extract the sample archive (app.asar, 414 MiB) posted in that thread (currently second to last post). It doesn't even look like the file listing is correct - over 100 files with a size of 1 GiB each in a 414 MB archive? That's just not possible.

Regards
Dalai

[iG0R]

Thanks a lot for the link, but it isn't my case.
I used it to unpack app.asar from the installation file of Chatbox https://chatboxai.app

Chatbox-1.2.6-Setup -> $PLUGINSDIR -> app-64 -> resources -> app.asar

I tested/verified this archive in 7-Zip, and no issues were found whatsoever.
I unpacked it using TotalCommander via Alt+F9, and it was successfully unpacked as well.
The problem only arises when I try to use View (F3) or Edit (F4) inside app.asar.

[Dalai]

Thanks for the sample.

Can confirm the issue. I'm pretty sure it's the Total7zip plugin's fault, perhaps indirectly. Such archives can be extracted in full via Alt+F9, single files can also be extracted via F5, but everything else shows the warning/error message: the verification (Alt+Shift+F9), viewing files from the archive (F3) and editing files (F4). The strange thing is that despite this message popping up, when dismissing it with OK the files are extracted fine (F3 or F4), they are shown/opened in Lister/editor respectively.

I still think this has something to do with checksums. Maybe there's a way to disable checksum checking for this particular format in Total7zip plugin somehow. Unfortunately I have no idea if this is possible or how.

Regards
Dalai

[iG0R]

Thank you for the idea, maybe I'll be able to do something with Total7zip.

[iG0R]

On the other hand, if it's the fault of the Total7zip plugin, this error should appear when performing any operation with this file, not only when trying to view, edit and verify.

[Dalai]

It's possible that no verification check is taking place when extracting the full archive or parts of it via F5, but they are performed when viewing or editing files. Maybe the behavior is changed by the Asar*.dll files.

I just checked the packer interface documentation. It doesn't look like there's a function informing the plugin which action is taking place. This means that extracting a single file (F5) and viewing a file (F3) looks the same to the plugin. For both of them TC probably calls ProcessFile with the Operation flag set to PK_EXTRACT. However, one of these operations leads to the warning/error message. I have no idea why.

Regards
Dalai

[petermad]

2Dalai
It sounds like it is when files has to be extracted to %TEMP% that the problem occurs - i.e. when Viewing, Editing and Verifying.

[Dalai]

But a verification doesn't extract anything, it just reads the archive (contents). I think TC calls ProcessFile with PK_TEST in this case. Let TC (or rather the Total7zip plugin) verify a very large archive, e.g. boot.wim or even install.wim from a Windows Setup DVD and while that's running check the %TEMP% dir in another TC instance. There won't be any files extracted to it.

Anyway, it looks like you are kind of right. I just tried extracting a file to %TEMP% manually via F5 and that also triggers the error message. Extracting to a directory just one level up (%TEMP%\..) works fine. Extracting the same file to %TEMP%\somedir\someotherdir also triggers the error message. And as I said above, the file is extracted fine when dismissing the error with the OK button. This is really weird.

Regards
Dalai

[Solf]

I seem to experience exactly the same issue, so curious if somebody has been / will be able to figure something out.