Can't create, rename or delete long filenames on FAT disks

[toncho11]

These were discussed in: #2159 (comment)
List:

• there is a problem with the ld linker from the 8086-toolchain. On Minix the toolchain works perfectly, but on FAT it fails
• handling of long filenames in FAT, currently files longer than 8 characters can not be deleted
• FAT is slower than Minix

We should make a difference between FAT16 and FAT32.
I also found this: https://serverfault.com/questions/529786/fat32-limit-on-total-length-of-all-filenames-in-a-directory-combined
It seems people on Windows also have problems. It says:

Now, obviously from observation, there seems to be some kind of hardlimit on how many characters can be used for all filenames inside a single directory for FAT32

Maybe it is the support for long filenames in that FAT is causing both the first and second problem.

[toncho11]

For example if the hard limit for long filenames on ELKS is much lower then on the Windows implementation? So we need to know what is the number of filename characters per folder for FAT32 for ELKS.

[floriangit]

FAT is slower than Minix

This was my main reason to use Minix, FAT was (not measured, but guessed) 50% slower compared to Minix on real hardware.

[ghaerr]

Thanks for opening this issue @toncho11. I suppose you weren't going to let the toolchain on FAT issue be tossed onto the back burner, since your primary real hardware testing is on FAT, right? :)

there is a problem with the ld linker from the 8086-toolchain.

I've identified exactly where the "upper level" of this problem occurs in the FAT filesystem: LD86 writes out the chess a.out header, then seeks forward ~6k bytes to a later section in the codefile. Upon trying to write that second section, the kernel goes into a loop with the FAT filesystem allocating all remaining FAT disk, but never attaching it to the file. The LD86 finally return with an out of space write error, and then we have a secondary problem that the toolchain stack sometimes overflows and/or segfaults when the filesystem has run out of space.

I worked on the FAT filesystem part of this problem for way too many hours last night, and came away with nothing. Its a real bugger. I'm regrouping and will dive in again later with hopefully some better ideas.

handling of long filenames in FAT, currently files longer than 8 characters can not be deleted

This is a known problem with ELKS LFN (DOS long file name) support: the kernel FAT driver can handle opening LFNs, but can't rename or remove them. Long ago, I got the original buggy LFN open code working, but there's no code at all for renaming or removing LFNs. Its a big project. We've worked around this so far by just limiting program name lengths, but it seems even this has been forgotten with the release of "objdump86" and other /bin programs like nxlandmine which, because of their filename length are subject to this problem. This is on my list but low priority.

FAT is slower than Minix

Unfortunately, FAT will likely stay much slower than Minix forever on ELKS. The real issue is that FAT is sector-oriented but has to run on top of a kernel "block" I/O subsystem, and 1K block size != 512 byte sector size. There's lots of kludgery that can't easily be changed. On top of that, FAT doesn't have inodes - they're entirely faked internal to the ELKS kernel and the file starting sector number is actually used as the ELKS inode. FAT doesn't support hard or symlinks either.

if the hard limit for long filenames on ELKS is much lower then on the Windows implementation? So we need to know what is the number of filename characters per folder for FAT32 for ELKS.

No, neither of these are an issue for ELKS. We've got plenty of space for long filenames and filename characters per folder.

[toncho11]

I created this issue as a reminder for the future.

Happy Holidays!