Homebrew NitroFS Error: Reading all 0xFF

[Cervi]

I'm working on a game built with libnds. I've got to a certain point where I've got over 90 files and 35MB in nitrofs data. For some reason, however, when I try to read the file named snd_floweytalk1.wav all the bytes returned by fread are 0xFF, so there must be some issue with loading the files. The thing is, it does not happen if I change the order of the files, or if I remove one of the bigger files preceding it. Anyone got any idea on why this is the case, or how I could possibly fix it?

Important information:
I already have 2 other file descriptors open when I open this file, although I don't think this has anything to do with it.
I used NO$GBA to debug and MelonDS, and both run into the exact same issue.
https://pastebin.com/utTPPvmz: Output of the `tree nitrofs -s` (structure of the nitrofs folder). The number preceding the file names are its size. I cannot share the folder and its contents.

Thanks in advance!

 

[FAST6191]

35megs "remove bigger preceding files"... I doubt it would be the case here but for some older flash carts there was a 32 meg limit or even smaller -- I remember having to slim down the tetris grand masters homebrew port by removing backgrounds to have it work on a GBA slot era thing. For practical purposes though then nitroFS should be in the gigabytes.

Order of files is an odd one. Ignoring the thing above and size cut offs then in commercial games (presuambly this too but not looked) then there is an option to go by file order rather than name as it saves a name lookup, why some games fail with ndstool and wanted nitro explorer 3 or something. Doubt it is some "file 30 is always bad" type deal but could be worth generating a few hundred blank bytes and pumping the order along by 1 just to see.

Beyond that I am really not sure, though I have not messed with the homebrew aspects when it comes to writing code so who knows.

 

[Cervi]

Seems the error gets fixed when I close one of the other file descriptors. Does nitrofs have a limit on how many simultaneous files can be opened? Or maybe opened in the same folder?

Edit: Nvm, the problem persists. It has to do with the bigger files preceding it.

 

[FAST6191]

I would not be surprised to see some fixed size array be used to store things such that shuffling something out of it/"closing" a file makes it work again. Whether it is limited to directories or is code wide you would have to bring up the code for and have a look, I doubt it would be directory wide (normally path lengths and name lengths get to be the greater concern) but that could also make for a bit more flexibility (whilst also losing the only reason to have fixed length arrays).

 

[Cervi]

I figured it out. NitroFS was trying to read from GBAROM (32MB max) instead of the card, so I made a modified version of libfilesystem in order to disable reading from GBAROM.

If anyone further on gets the same issue, clone libfilesystem and modify line 132 in nitrofs.c to include "&& false".