SofaUnZip bug report thread

Page 2/2
1 |

By Grauw

Ascended (9273)

Grauw's picture

25-02-2020, 01:08

Louthrax wrote:

The main "root of evil" so far with SofaUnzip is the "pre-allocation" step when creating a new file (the hang is not happening at the end of a file extraction, but during the pre-allocation of the next one). This pre-allocation step gives a huge speed-improvement on crowded SD-cards, but this calls MSX-DOS2 in a way that's not commonly used and tested (still respecting the standard though).

One MSX-DOS2 implementation that was not handling that well was IDECDEX, for which I provided a patch on my WebSite.

On Nextor, it looks different: the hang seems (not 100% sure) to be linked to the use of the "stdout" device to print text and the use of MSX-DOS2 "fflush" function required after the pre-allocating step...

Something I need to update in Gunzip as well?

https://hg.sr.ht/~grauw/gunzip/browse/bf0080c4e9/src/Applica...

By Louthrax

Prophet (2280)

Louthrax's picture

18-01-2017, 14:53

If people using Gunzip have my patched IDECDEX v1.3 driver (or no CD driver installed), it should work fine on IDE & MSX-DOS 2.

On Nextor, you just want to avoid using MSX-DOS 2 function 49h "Write to file handle" on STDOUT to output text (but you have your own BIOS-type functions if I remember your code correctly Smile, so that should be fine). I have been using this way to output text in order to allow redirection of output to a file (commands like "suz l foo.zip > res.txt"), before discovering this also works with MSX-DOS 1 functions...

By Grauw

Ascended (9273)

Grauw's picture

18-01-2017, 15:33

Ah ok, good to know! Indeed I don’t use file handles to output text. Bug report to Nextor I guess Smile.

By Louthrax

Prophet (2280)

Louthrax's picture

18-01-2017, 17:32

Grauw wrote:

Ah ok, good to know! Indeed I don’t use file handles to output text. Bug report to Nextor I guess Smile.

Yep, I already reported that to Nestor.

By PAC

Guardian (5810)

PAC's picture

19-01-2017, 01:12

Louthrax wrote:

Anyway, the latest version of SofaUnzip should have fixed that. My hope here is that maybe you still had an old version of SUZ.COM and that extracting SOFARUN.ZIP did overwrite it with the new version...

After some verifications, I have to admit you are right. First of all I noticed that the previous version I had on my SD didn't show the sentence "SofaUnZip v1.2 (c) 2016 by Louthrax and Grauw" and no other just running the .COM file. On the other hand the size of this "bad" SUZ.COM file is 13860 bytes instead 13786 bytes (the correct size of the 1.2 version). So the file was probably corrupted, anyway I could extract some files succesful.

If I'm not wrong there haven't been a previous version before 1.2 recently, right? I downloaded SofaUnZIP for the first time just a month ago or so. I suspect the problem could be related with my current PC ZIP tool which doesn't extract the files with the correct size or something like that because yesterday, as I pointed out, I downloaded again SofaUnZIP from your website, put it in a separate directory and I experienced the same problem. I confirmed that PATH from the AUTOEXEC.BAT was not running the "bad" version too.

I don't understand what happened. Sorry for any inconvenience and thank you for your help. Mistery solved and you can sleep well Wink.

By gdx

Prophet (3680)

gdx's picture

01-05-2019, 12:28

Hi Louthrax,

Can you add an option to select the destination? That is missing a lot.

Page 2/2
1 |