devkitPro

Ok, you can find the linux wrapper for testing here: http://cfg-loader.googlecode.com/files/libfat-106-linux.tgz I have already updated it to version 1.0.6 of libfat. To try it out run this: cd libfat-106-linux/source make cd ../test make sh runtest.sh runtest.sh is this: dd if=/dev/zero of=fat.dat ...

ok, submitted. https://sourceforge.net/tracker/?func=detail&aid=2885644&group_id=114505&atid=668553 it of course needs a thorough review and testing. also i made a wrapper for linux to use libfat in a user process which i used to test and debug the code, do you want me to upload that too...

Ok i think i made a proper fix that solves both problems that i posted. Should i go ahead and post the diff here? It's not as short as the previous one and i don't know if this is the right place and if anyone is interested? Do only I get corrupted files using libfat?

ah, the fix is not proper, it causes all files to allocate more clusters than used
so the problem remains

and i think i found another work-around for this. instead of doing loop{open/write/close}, this works too: open() loop{ lseek(0, SEEK_SET) // begin of file lseek(0, SEEK_END) // end of file write() } close() oh and to make it more clear this is what is problematic: open(); loop { write() }; close();

It seems to me that if you do multiple writes to a file then the cluster allocation or something gets corrupted. If you check the FS afterwards on windows, it will report problems and extend the file by 1 cluster, while linux fsck.vfat will truncate the file by some amount... while doing an open(O_A...

example with FAT16 and 32k cluster size, a simple write of 32k will crash libfat. i traced down the problem to be in the last commit, reverting one change fixes it, see below: is this a valid fix or is there something else to it? --- libfat-105-x/source/fatfile.c 2009-10-08 22:06:48.000000000 +0200 ...