Products > Programming

Converting long filenames to 8.3

(1/3) > >>

peter-h:
I am writing a simple web server which has a file upload feature.

FatFS is used to implement a FAT12 (2MB) flash file system, with LFNs disabled.

However, the windows file picker does make it possible for someone to select a long filename for upload.

Would FatFS convert this to 8.3 or do I have to do that?

And if FatFS doesn't do that (I suspect it will fail the f_open if it got a non 8.3 valid filename) can anyone suggest a way to do the conversion? There are various crude filename truncation routines out there. I think the one which windows uses needs to have access to the entire directory though, to avoid conflicts.

Many thanks in advance for any pointers.

I could just reject such a file at the upload point, as I have to do anyway if e.g. it is bigger than remaining filespace. But it would be better to truncate it.

I don't have any need to do the extra stuff e.g. rejecting filenames like COM2 LPT1 etc.


Ed.Kloonk:

--- Quote from: peter-h on August 06, 2022, 10:14:24 pm ---I am writing a simple web server which has a file upload feature.

FatFS is used to implement a FAT12 (2MB) flash file system, with LFNs disabled.

However, the windows file picker does make it possible for someone to select a long filename for upload.

Would FatFS convert this to 8.3 or do I have to do that?

And if FatFS doesn't do that (I suspect it will fail the f_open if it got a non 8.3 valid filename) can anyone suggest a way to do the conversion? There are various crude filename truncation routines out there. I think the one which windows uses needs to have access to the entire directory though, to avoid conflicts.

Many thanks in advance for any pointers.

I could just reject such a file at the upload point, as I have to do anyway if e.g. it is bigger than remaining filespace. But it would be better to truncate it.

I don't have any need to do the extra stuff e.g. rejecting filenames like COM2 LPT1 etc.

--- End quote ---

My limited understanding of extended filenames when it was coming in to winx/dos was that the OS, for compatibility, bestowed a legacy truncated 8.3 filename and that whatever lib used the file services (old or new) could operate seamlessly, with varied results.

Unless, I don't fully understand your issue, whatever it is writing to the old filesystem should be truncating the filename, shouldn't it?

SiliconWizard:
FatFs will not do anything about it, especially if LFN is disabled.

If you're directly managing file creation with f_open() and the file names come from a HTTP request (as I suppose given your project), you will unfortunately have to deal with that yourself.

Since you're using FAT12, you can't support LFNs, so you don't need to use the "official" way of generating 8.3 names from LFNs. The original file names will be unrecoverable anyway. So you basically need to write a function that will transform the name: remove characters that are not supported for 8.3 FAT names, limit to 8 characters (+ 3 max for the extension if any). Now you'll also have to avoid file name collision - meaning that once you get such a 8.3 name, you need to check whether there isn't already a file with the same name in the same directory - if so, you'll have to transform the new name with a numbering scheme (while removing the necessary last chars of the 8 part of the name to accomodate). This is pretty tedious, but I don't see any other way.

Note that this is not just a problem of length. Only a restricted set of characters are valid for 8.3, so if the filename, even if short enough, contains any non-supported character, that will fail as well. If you have no control over the files the user can pick, then you need to handle this too.

One problem with this scheme is that if you want your users to be able to replace an existing file and said file originally has a long file name, then you can't: no way of knowing this was the same file name, so all you can do is save the new file while the old one will be still there with a different number (or no number if it was the first one.)

The joys of FAT.

ledtester:

--- Quote from: peter-h on August 06, 2022, 10:14:24 pm ---And if FatFS doesn't do that (I suspect it will fail the f_open if it got a non 8.3 valid filename) can anyone suggest a way to do the conversion?

--- End quote ---

What exactly is your use case? Do you have to remember the filename the user uploaded or why not just generate your own file name like from a random number or a sequence counter?

For instance, consider how this forum works. At the end of this message I've attached the same text file three times but they all have different links:

- https://www.eevblog.com/forum/programming/converting-long-filenames-to-8-3/?action=dlattach;attach=1559716
- https://www.eevblog.com/forum/programming/converting-long-filenames-to-8-3/?action=dlattach;attach=1559719
- https://www.eevblog.com/forum/programming/converting-long-filenames-to-8-3/?action=dlattach;attach=1559722

peter-h:
This is as I suspected - not trivial.

The algorithm which M$ use can't be trivial because after truncation you need to keep incrementing the numeric part while checking for a name collision after each one. I don't think it is doing that, because on a PC you could have 10k-100k files (in a subdir, anyway) so it must grab a linked list of the files, sort it, and determine the first candidate for a truncated filename.

Also the directory is quite likely to already contain files with M$-truncated names. You can see one here



So just picking up one will yield an immediate collision :)

I will just refuse to upload a long filename...

The use case is an embedded filesystem, FAT12, LFN disabled (FatFS implementation) with a file upload feature, accessible via an HTTP server (in the pic) and I can't actually stop somebody trying to upload a long filename.

The filesystem is also accessible via USB, as a removable block device, and there windows just sees plain 512 byte sectors so it does what it likes in there. If you write a LFN that way, the embedded side sees just the 8.3 filename, so that works ok.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version