Hacking Extremely weird filesystem behavior

[Quaxo76]

OK, this is possibly the weirdest filesystem behavior I've seen in 30+ years of computer usage. I would really love you filesystem experts to shed some light on this.
I'll keep the story short, but to summarize: I have an Ace3DS+ flashcart. It wouldn't load most newer games, but I didn't want to give up and experimented a bit... After replacing the usrcheat.dat file with the newest available, still no joy; then I trimmed the incompatible ROMs, and they started working. All of them. And here comes the weird part.

I wanted to replace the SD card with another one, so I just copied the files over another card (same FAT32 formatting). It wouldn't work. (The older games would work, the newer ones wouldn't).
I made sure that the firmware on the SD card was the same as the old one. I reinstalled the newer usrcheat.dat file. Nothing.
I realized that I had copied the untrimmed ROMs, so I trimmed them. Nothing.
So I got an older backup on my computer, and I copied over an already-trimmed ROM to the SD. That one worked. So I suspected a corrupt file, or wrong file attributes.
I checked the sha256 checksum on both files (the old backup and the newly trimmed one) and the checksums match exactly.
I checked the attributes and they match. I checked timestamps and they match. I can see absolutely no difference in the files. I also renamed them just "1" and "2" to rule out weird file names. One kept working, and the other kept crashing. Even though the checksum says they're absolutely the same file.
So I deleted the working one, and made a copy of the non-working one, in the same folder (I don't even know why I tried this). Surprise... the original file crashes, the copy that I just made FROM THE CRASHING FILE works perfectly.
So I went ahead and made a copy of all the non working games, on the same SD... without changing anything... And the copies ALL work. I mean, I have many non-working files, and just making a copy of them in the same folder, I get a working copy. Consistently. And the attributes, time stamps, and checksums all match exactly between the non-working originals and the working copies.
I'm absolutely stumped. Those two copies of all those games are ABSOLUTELY the same file, yet one set works and the other doesn't.
(I had also tried moving the non-working files around, to other folders, in case there was some black-list or log or something preventing them from running from their original location.)
I also tried making a copy, then deleting the non-working original, then renaming the copy as the original... and it worked.

Now, it's true that I solved my immediate problem (I have a complete working game set), but I won't be able to sleep until I figure out why two absolutely identical files behave so differently... Any ideas, anyone?

(I tried the file operations and the attribute checks / checksums both on Windows and on Linux, to rule out OS problems).

Thanks,
Cristian

 

[Nikokaro]

Hello. I have absolutely no answer to your issue, but in return I have bumped your thread.
Some time ago I ordered a 482 in 1 ds cartridge on ebay, and when it arrived, to my great surprise, I found out that it was an Ace3ds+ flashcart with a microSD included.

Basically I bought it to keep it as a spare, but bearing in mind the problem you reported, I will surely replace the SD with a 32gb one, directly installing the most updated kernel/firmware, obtainable from its website.

I am also curious to know if there is a scientific explanation for your matter.

I don't think anyone could give you a satisfactory answer, since what you have described defies all logic and common sense; but from these chinese clone carts you can expect anything, even impossible ones.

 

[GothicIII]

Difficult to tell but I bet it is the kernel you are using for the Ace3DS flashcard.
Often the flashcards used a dodgy implementation of the FAT filessystem and fopen/fclose functions. For me it was at least 15years ago but I experienced all kind of weird stuff with a M3Simply. Like Games not saving when they have a space/dash in the filename. Or the game list is missing games because the card did not support more than like 32 games in a folder.

So it has nothing to do with the filesystem in general.
FAT32 limitations are really hard to reach with a nds flashcard. Here are some:
-max 255 chars path length
-4GB file size (2^32 - 1 bytes)
-max 65534 files in a folder

 

[boots_n_cats]

I've seen this too. The Ace3DS+ clones and relatives seem to have some weird issues with certain SD cards and FAT32 configurations. I've seen random changes in settings (e.g. the save file extension) make games start or stop working. It may also depend on which direction the wind is blowing as far as I can tell. I think the actual FAT implementation that is built into the the COB ASIC hidden under the epoxy blob is limited by how cheap the IC is and can only handle so much fragmentation, limited cluster size ranges, and how much latency it will tolerate from the SD card. Basically, cheap flashcart is cheap.

I still suggest the Ace3DS+ clones since they are super cheap and the alternatives haven't been any better for a while. The one maybe kinda good cart you can now get is the DSONE carts sold on AliExpress but I've heard of at least one coming DOA so I don't know if they are reliable enough to be recommending to people who may struggle to format an SD card.