I once attempted to implement such a thing, but it turns out that this file naming behavior is oddly difficult to replicate 🤪

Oerg866 wrote on 2025-03-25, 08:35:

I once attempted to implement such a thing, but it turns out that this file naming behavior is oddly difficult to replicate 🤪

Maybe steal some code from DOSBox? Or the Linux or BSD msdosfs implementations? At least the former has to actually construct correct 8.3 FAT entries with LFNs from whichever underlying filesystem you have. And the msdosfs code needs to do the same whenever you attempt to create new files:

FreeBSD sys/fs/msdosfs/msdosfs_conv.c (direct link to the unix2dosfn() function)

I have no idea if it's possible, "easy", or how to adapt this to etherdfs so .. I'm sorry I can't help more :(

ltning wrote on 2025-04-03, 11:20:

FreeBSD sys/fs/msdosfs/msdosfs_conv.c (direct link to the unix2dosfn() function)

I had a look at this and the problem I'm facing is that the generation number is an *input* to this function; I do not know how to generate it, nor can I find a definitive spec on how to do so...

Oerg866 wrote on 2025-05-13, 01:41:

ltning wrote on 2025-04-03, 11:20:

FreeBSD sys/fs/msdosfs/msdosfs_conv.c (direct link to the unix2dosfn() function)

I had a look at this and the problem I'm facing is that the generation number is an *input* to this function; I do not know how to generate it, nor can I find a definitive spec on how to do so...

I vaguely recall discussing this with someone a long time ago, and (with the danger of sounding completely clueless) I think the approach was to call that function, check if the result already exists in the virtual directory, and call it again with an incremented number if it does.
Whether that is what FreeBSD is actually doing, I don't know..

Thanks for your efforts on this!

/Eirik

Oerg866 wrote on 2025-05-13, 01:41:

ltning wrote on 2025-04-03, 11:20:

FreeBSD sys/fs/msdosfs/msdosfs_conv.c (direct link to the unix2dosfn() function)

I had a look at this and the problem I'm facing is that the generation number is an *input* to this function; I do not know how to generate it, nor can I find a definitive spec on how to do so...

Isn't it just an increasing number based on the alphabetical sorting of the list? And only added if multiple identical matches are found or the filename is too long (past 8 characters)?

superfury wrote on 2025-05-13, 09:26:

Isn't it just an increasing number based on the alphabetical sorting of the list? And only added if multiple identical matches are found or the filename is too long (past 8 characters)?

Sadly it is not that simple :\ For example, if you have two files:

Invoice Frank.docx
Invoice Peter.docx

You'd have these two:

INVOIC~1.DOC
INVOIC~2.DOC

But, if you then delete Invoice Frank.docx, to my knowledge, Invoice Peter.docx will still translate to INVOIC~2.DOC, even though there is only one file left.

I'd essentially have to implement a little FAT database that keeps track of every single file ever created, renamed, deleted, etc., which gets messy very quickly :\

Oerg866 wrote on 2025-05-18, 11:32:

Sadly it is not that simple :\ For example, if you have two files: […]
Show full quote

superfury wrote on 2025-05-13, 09:26:

Isn't it just an increasing number based on the alphabetical sorting of the list? And only added if multiple identical matches are found or the filename is too long (past 8 characters)?

Sadly it is not that simple :\ For example, if you have two files:

Invoice Frank.docx
Invoice Peter.docx

You'd have these two:

INVOIC~1.DOC
INVOIC~2.DOC

But, if you then delete Invoice Frank.docx, to my knowledge, Invoice Peter.docx will still translate to INVOIC~2.DOC, even though there is only one file left.

I'd essentially have to implement a little FAT database that keeps track of every single file ever created, renamed, deleted, etc., which gets messy very quickly :\

Hmmm... Can't you simply enforce FAT32 (or VFAT?) drives being used in Linux for mounted folders and request the short filename path from the driver?
https://github.com/torvalds/linux/blob/master … at/namei_vfat.c

Obviously, but who wants to force themselves to format their archival hard drives to FAT32? I certainly don't 😜

In vboxsf , what I do is that long filenames are shortened to a 4 letter prefix, a ~, and a 3 letter hash of the long name, plus the extension. E.g. LONG~20B.TXT .
This way you ensure that there are no file name conflicts (because it is unlikely that multiple long file names with the same prefix resolve to the same hash, but if this is really a problem you can also increase the number of digits dedicated to the hash) , and that the short filenames do not change if you reboot or remove other unrelated files from the directory (the hash is the same as long the actual long filename does not change).

Note that both the idea and implementation actually come from https://github.com/eduardocasino/vmsmount .

superfury wrote on 2025-05-18, 12:04:

Hmmm... Can't you simply enforce FAT32 (or VFAT?) drives being used in Linux for mounted folders and request the short filename path from the driver?

Oerg866 wrote on 2025-05-18, 12:38:

Obviously, but who wants to force themselves to format their archival hard drives to FAT32? I certainly don't 😜

In the case you use a modern Linux filesystem, the short names can be stored in extended attributes instead.