How to read the LFN for a file?

[neil-morrison44]

Apologies if this is already in an example somewhere but I’ve not spotted it.

I need to somehow read the large file name for a file. I don’t mind getting an iter back of all the short file names for the file & having to compose the long file name myself, if that fits better with no_std & how FAT works.

I see the is_lfn property but I’ve not yet found anywhere that comes back as true - even the files which end in ~1.

Ideally I want to retrieve a file using the large file name (but I can see how that could be out of scope)

[thejpster]

You'll probably need to write an alternative version of iterate_dir - something like iterate_lfn_dir. That function will need to be given a mutable byte slice it can store the filename in, and the DirEntry structure given to the callback will need to become some LongDirEntry structure that can contain a Option<&str> backed by the byte slice that was passed in.

The logic would be that as you iterate, if you see an LFN fragment you convert the UCS-2 characters to UTF-8 and push them into the storage byte slice. Then when you get a non-LFN dir entry, you do the checksum, and if it matches, pass that filename in the LongDirEntry.

You could just modify iterate_dir but that would break backwards compatibility, so maybe two methods is best for now.

[thejpster]

Oh and IIRC is_lfn is only true if the directory entry is a Volume Label, is Archive, Hidden and Read Only - that basically never happens (unless it's an LFN fragment). MS-DOS and Windows deliberately won't show you the fragments - MS-DOS ignores them completely and Windows assembles them into a long file name.

You can probably force Linux to mount a volume without LFN support and get it to show you the fragments. Or you can just read https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#VFAT_long_file_names. Or you can patch the embedded-sdmmc code to not hide the fragments (although note, some of the chars are stored in the timestamp fields so the entries look really weird).

[thejpster]

See #12 and the PR #155