uSD read full file names

threadz

Is it possible to read the full names of files on a micro SD card rather than the 8.3 names? If not, does anyone know where I would begin reading up on file FAT32 file systems to understand how that info is stored so I can implement it myself?

JonnyMac

You can open files with long names, but you have to use 8.3 format with FSRW. For example, in an app I'm working on I have an audio file called 001_GAMEOVER.WAV but I have to use 001_GA~1.WAV in my Spin listing.

Kye

I think pik33 modified my driver already to do this. Check this out: http://forums.parallax.com/showthread.php/140767-A-new-topic-for-vga-(not-only)-sid-player

threadz

Is there any chance you've seen it adapted for C/C++?

Kye

No, sorry. However: http://elm-chan.org/fsw/ff/00index_p.html

You just need to fill in the block driver code.

DavidZemon

threadz wrote: »

Is it possible to read the full names of files on a micro SD card rather than the 8.3 names? If not, does anyone know where I would begin reading up on file FAT32 file systems to understand how that info is stored so I can implement it myself?

This has been haunting me for a while, and the feature may well find its way into PropWare someday. I have lots of documentation on FAT16/32 filesystems from a course I took - I've uploaded it here: http://david.zemon.name/downloads/fatDocs.zip
I also opened an issue for PropWare for long filenames but set the milestone to "someday" :P

DavidZemon

If you're going to attempt long file names for yourself in C/C++, I would think you'd be best off going with either modifying Parallax's code in PropGCC or libpropeller's SD implementation. I'm not sure if there are any other existing versions out there. Maybe something from Catalina?

Peter Jakacki

I didn't want to implement LFN in my FAT32 implementation because it is not really needed for starters as the biggest user of SD cards are digital cameras which stick to 8.3 and this also applies equally well to embedded systems. Another reason is that LFN is a kludge on a kludge, there are dozens of better ways to implement LFN and still be compatible but I feel MS did it this way for patent protection as LFN requires a license from MS, which is another reason I avoid it.

There is no need to generate an LFN on an embedded system although it can be convenient to read one that was put there by a PC, but if the file name can be up to 255 characters then that means you need to allocate that memory for the search string at least. On a PC with Gigabytes of memory that is never a problem, on a Prop with 32K RAM for both code and data that is a big drain on resources. Think about whether you really need LFN, perhaps you do, but I know I can get by very nicely without it and if MS file system would allow plug-ins then it would be very easy to come up with an open LFN scheme that could be read by any PC, much like codecs allow various formats, but this would be very much to the detriment of MS's One World O/S domination scheme (and yearly license).

msrobots

Besides the license issue LFN of Microsoft is quite easy. The first directory entry contains the short 8.3 entry and the following directory entries (up to 255 bytes) contain the long filename, marked with a flag to distinguish from normal entries.

Easy to read with Kyes Fat_engine or FSRW. Not so easy to write because you might need to shuffle around existing entries to get the needed space behind your existing directory entry.

As Peter says it is not the smartest implementation.

I've played around with TAR as a file system in a file on top of FAT32. Way easier to handle with the Prop.. But - alas - it is on ice like the RAISD system, Editor18 and ISAM.

Sad!

Mike