duplicate filename errors when copying files with long paths to GemDrive

[phjanderson]

First of all, the SideCartridge is a brilliant device. Thanks for making it and sharing it with us!

I'm trying out the GemDrive feature and I'm getting duplicate filename errors when copying all my files from my ACSI2STM (in ACSI mode) using ICD Pro to the GemDrive of the SideCartridge. I'm using the beta-v0.0.17 firmware with a 32gb fat32 formatted MicroSD card. I use a Mega STE with TOS 2.06

When comparing the differences between the original and copies, I notice that parts of the filenames/extensions were lost. When checking the total path length, it seemed to add up to 64 characters (including the drive letter). Is there a limit of 64 characters?

I tried creating nested folders on my ACSI2STM ICD Pro drive: 11111111.111\22222222.222\etc and couldn't find any limit (stopped after 20-30 or so sub folders). I tried the same on the GemDrive. When I got to 55555555.555, the folder name was created as 55555555. I could no longer create anything within that folder.

S:\11111111.111\22222222.222\33333333.333\44444444.444\55555555 adds up to 63 characters (64 if you count the missing trailing dot).

So two sub issues:

• if a path limit is exceeded, wouldn't it be better to throw a write error or such?
• can the path limit be extended (for example to the TOS limit or 255?)

Other than that the GemDrive seems to work quite well and is reasonably fast. I'm also happy that it works with the Mega STE cache enabled. The GemDrive support of the ACSI2STM fails whenever I enable the cache. So great work!

Thanks!

[diegoparrilla]

Thanks for submitting the bug. There is a limit of 125 bytes in the size of the GEMDOS path in the TOS (Atari GEMDOS Reference Manual, page 6), but 64 is too short so there must be a bug in the code of the GEMDRIVE. The size in the GEMDRIVE size should not have large boundaries (256 bytes should be more than enough).

My educated guess is there is an error when converting the path from (GEM)DOS format to *NIX format in the microcontroller, or a hard boundary that did not trigger an error.

I will investigate on that and will be included in the next release (hopefully in 1-2 weeks).

[phjanderson]

Thanks for the swift response! No hurry!

There is a limit of 125 bytes in the size of the GEMDOS path in the TOS (Atari GEMDOS Reference Manual, page 6)

Indeed, it's weird limit however. After submitting this issue, I tried removing the 11111111.111\22222222.222\etc folder structure from the ACSI drive and I got an error. I was able to remove the folders by deleting the folders from the deepest level and working myself up again, until eventually the structure was within the 125 limit again.

I took a quick look through the code of this project and atarist-sidecart-gemdrive. It's somewhat difficult for me however as I'm not familiar with your code, the GEMDOS APIs and I haven't touched 68000 assembler in over 30 years. I do have some recent C experience however.

In the method get_local_full_pathname in romemul/gemdrvemul.c is the following code:

    for (int i = 0; i < MAX_FOLDER_LENGTH / 2; i += 2)
    {
        path_filename[i] = (char)*(origin + i + 1);
        path_filename[i + 1] = (char)*(origin + i);
    }

You both divide the MAX_FOLDER_LENGTH and increment by 2. MAX_FOLDER_LENGTH is set to 128, so that would result in an effective limit of 64. I think the / 2 should be removed, perhaps that solves the issue?

Perhaps you could also add in some check here or elsewhere to throw an error if MAX_FOLDER_LENGTH is exceeded?

[diegoparrilla]

You were right; the code highlighted was part of the problem. It was also wrong in other places, copying only 64 bytes instead of the 125 limit.