SofaUnZip bug report thread

Page 2/2
1 |

By Grauw

Ascended (9683)

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 (2399)

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 (9683)

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 (2399)

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 (6159)

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

Enlighted (4179)

gdx's picture

01-05-2019, 12:28

Hi Louthrax,

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

By dankcomputing

Supporter (7)

dankcomputing's picture

28-02-2021, 05:55

I've been having some trouble with archives that have nested folders. If I try to extract a ZIP file (for example this game here at http://frs.badcoffee.info/files/PSYCHOHD.ZIP), it will error out when it reaches the files that are nested 2-3 levels deep. It gives a "Error, file already exists: VISUAL1.BIN" error when it reaches PSYCHO/LANGUAGE/JP/VISUAL1.BIN during the extraction. The total path length isn't even at the 63 character limit so I'm kind of stumped.

By Louthrax

Prophet (2399)

Louthrax's picture

28-02-2021, 09:12

I tried it here with the archive you mentionned but couldn't reproduce the problem.

Some extra questions:

  • Are you using SofaUnZip from the command line or with the SofaRun Copy / Paste commands ?
  • Are you sure the file does not already exists ?

Also, there's an option in SofaUnzip to overwrite existing files (/o), but of course you shouldn't need that if the file does not already exist.

EDIT: So I guess you are using command line and used the 'e' command to unzip the file. This command does not take the paths into account (so you get duplicated file names because of the different languages in the archive). Just use the 'x' command instead.

By dankcomputing

Supporter (7)

dankcomputing's picture

03-03-2021, 04:39

I'm using it from the command line. The behavior is the same whether I use the "e" or the "x" switch. I haven't tried the "overwrite existing files" switch, would be interesting to see what happens.

By dankcomputing

Supporter (7)

dankcomputing's picture

28-03-2021, 08:20

I tried again after reformatting and reinstalling everything on a different CF card and it's almost impossible for me to reproduce the bug now. I suspect something was wrong with my old setup.

Page 2/2
1 |