Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to read the LFN for a file? #91

Open
neil-morrison44 opened this issue Jul 29, 2023 · 2 comments
Open

How to read the LFN for a file? #91

neil-morrison44 opened this issue Jul 29, 2023 · 2 comments

Comments

@neil-morrison44
Copy link

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
Copy link
Member

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
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants