#159141 - fluff - Thu Jun 26, 2008 2:34 am
| Code: |
FILE * f = fopen( "/long_filename.txt", "wb" );
|
creates a file called "long_fi?" in the root. The fopen call succeeds, but anything I write to that descriptor is lost.
| Code: |
FILE * f = fopen( "/filename.txt", "wb" );
|
works fine.
I have no problem opening files with long filenames for _reading_, and the dir functions retrieve LFNs correctly.
Has anyone got hints, clues or solutions? If it's a problem with libfat it seems like a big enough deal that someone else would have noticed.
I've tried libfat 20070127, 20071116, and a personally compiled version from libfat-src-20080530.tar.bz2, all with the same frustrating result.
Another odd thing is that fatInitDefault() takes around 5 seconds on all libfats I've tried except 20071116 which is virtually instantaneous. Any idea why?
I'm running an NDS lite and CycloDS (firmware 1.4B2) with an 8GB SanDisk card. devkitARM 23b. libnds 20071023.
I've been using libfatdragon until now, but that one's got its own problems. It does however work perfectly with long filenames on my system, freeing the CycloDS from some suspicions...
Cheers and thanks!
#159147 - sgeos - Thu Jun 26, 2008 5:05 am
Do you know exactly how long "long" is? At what string length does the library routine start to fail.
The workaround is obvious- use short file names. There were days when people had to do this. (I'm glad those days are basically gone.)
-Brendan
#159160 - fluff - Thu Jun 26, 2008 11:18 am
I'm assuming it screws up as soon as the length's more than 8.3, but I'm heistant to test too much for fear of file system corruption.
The obvious workaround isn't really viable in this case. I'm writing a web downloader and I'd rather like the downloaded files to keep their names. :)
Any good ideas on where the problem might lie? As I said, it seems odd to me that libfat should still have a bug this big. The fact that libfatdragon works fine makes me think that might actually be the case though.
I guess I could start tearing through the libfat sources, but I was hoping I wouldn't have to -- it makes me a little nervous...
#159162 - Dwedit - Thu Jun 26, 2008 11:52 am
FAT16 has a fixed number of entries allowed in the root directory, and long filenames eat up multiple entries. Try FAT32 instead?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#159163 - tepples - Thu Jun 26, 2008 12:12 pm
| fluff wrote: |
| I'm assuming it screws up as soon as the length's more than 8.3, but I'm heistant to test too much for fear of file system corruption. |
Do you think the corruption caused by testing might be something that even a reformat can't fix? If not, I'd recommend backing up all the files from the card, doing the testing, reformatting the card, and then putting the files back on.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#159165 - fluff - Thu Jun 26, 2008 12:32 pm
Oh, I'm already on FAT32 unfortunately.
What the... Uh, it works fine when I try running the test program today.
Curiouser and curiouser...
Perhaps the FAT was a little corrupted from earlier abuse by libfatdragon and others and that caused libfat to fail? Then after some remedial workover by libfat the file system is now (more or less) cured? I don't know, just a guess. Or maybe the poor thing just needed some sleep. Any better ideas?
The fatInitDefault() 5-second delay for everything but libfat 20071116 remains though. Does that happen to anyone else or is that also just me?
Many thanks for your input so far!
#159166 - tepples - Thu Jun 26, 2008 12:41 pm
| fluff wrote: |
| Perhaps the FAT was a little corrupted from earlier abuse by libfatdragon and others and that caused libfat to fail? Then after some remedial workover by libfat the file system is now (more or less) cured? |
Did you try chkdsk? That always seemed to fix the problems that libfatdragon of DSOrganize pre-3.x would cause for me.
GUI chkdsk (easier for novices)
My Computer (Windows+E) > Devices with Removable Storage > J: > right click > Properties > Tools > Check Now
turn on "Automatically fix file system errors" and press Start
CLI chkdsk (see what problems get found and fixed)
Start > All Programs > Accessories > Command Prompt
chkdsk /f J:
(replace J: with the drive letter of your card)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#159168 - Dwedit - Thu Jun 26, 2008 1:18 pm
I just noticed that Dragonminded's version of gba_nds_fat has significant differences with the gba_nds_fat used in nesds.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#159169 - fluff - Thu Jun 26, 2008 1:39 pm
| Quote: |
| Did you try chkdsk? |
Good idea! Turns out there were quite a few "Removing nonvalid long folder entry from \..." as well as a smattering of "\_code Errors in . and/or .. corrected." and "More than one MOONS~01 entry in folder \."
73 problems in total... libfat's anger seems reasonable enough.
| Quote: |
| I just noticed that Dragonminded's version of gba_nds_fat has significant differences with the gba_nds_fat used in nesds. |
Unfortunately I think libfatdragon's still got bugs. Every now and then (maybe <5% of the times) when I created files (even with 8.3 filenames) they wouldn't show up in the file system. Chkdsk found them now though. :) Of course, those bugs could also be a result of prior FAT corruption, but that seems far from certain.
I was mildly hoping the 5 sec fatInitDefault() delay would disappear as well now after the chkdsk cleanup, but no such luck. I guess I could live with it, but it does add a precious 5 seconds to the dev cycle. ;) I should compare libfat 20071116's fatInitDefault() with the other ones...
#159438 - silent_code - Mon Jun 30, 2008 10:40 pm
Ok, I have had a very simmilar problem (libfat 20070127 [most recent as of writing]) and found out, that the whole path must not be longer than 32 characters (including "fat:/" and '\0'), or else the file will not be found.
Until now I have only tested this on no$gba with FCSR (might also cause the problem - we'll see if things work on the hardwarwe.) It's strange.
I haven't tried to chdir and then load a file... maybe it's just a buffer problem, where the size of the filename buffer is hardcoded with 32 (quite small, isn't it?)
I'll investigate further. Well, that is, if I don't "switch." (EFS2.0 seems to be quite tempting right now [Sorry eris! <silly voice> Please *understand*, it has *WRITE support*! X^D ])
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.