AVR Freaks

Hmmm--nothing to do with the space in the file name?  From the Wikipedia article:

Furthermore, in these systems file and directory names are uppercase, although systems that use the 8.3 standard are usually case-insensitive (hence CamelCap.tpu will be equivalent to the name CAMELCAP.TPU).

The case-insensitive would be my experience, AFAICR.   For example, FATfs:

Legal Characters and Case Sensitivity

On the FAT filesystem, legal characters for object name (file/directory name) are, 0-9 A-Z ! # $ % & ' ( ) - @ ^ _ ` { } ~ and any extended character. The valid character codes of extended characters are depends on the configured code page. Under LFN supported system, also + , ; = [ ] and white space are legal for the object name and the white spaces and dots can be placed anywhere in the path name except for end of the name.

FAT filesystem is case-insensitive to the object names on the volume. Object name on the FAT volume is compared in case-insensitive. For instance, these three names, file.txt, File.Txt and FILE.TXT, are identical. This is applied to extended charactres as well. When an object is created on the FAT volume, up converted name is recorded to the SFN entry, and the raw name is recorded to the LFN entry when LFN function is enabled.

As for the MS-DOS and PC DOS for CJK (DOS/DBCS), extended characters are recorded to the SFN entry without up-case conversion and compared in case-sensitive. This causes a problem on compatibility with Windows system when any object with extended characters is created on the volume by DOS/DBCS system; therfore the object names with DBCS extended characters should not be used on the FAT volume shared by those systems. FatFs works with case-sensitive to the extended characters at only non-LFN with DBCS configuration (DOS/DBCS specs). But at LFN configuration, FatFs works with case-insensitive to the extended character (WindowsNT specs).

Well, a moderator had already replied to the post, and did not see fit to address any possible miscreance.  So then the content >>must<< be appropriate, right?  Essentially, a request for clarification.

That doesn't stop me from spotting the embedded space in a scroll through the thread.  And indeed, I missed that it was a directory name ("folder 1" -- duh).  IME file names are usually handled as FATfs does it.  Your experience is different -- you used to work on floppy-based STBs, right?

Just curious -- how much did the license cost you?

I dug this up during an e-mail discussion with Horacio Gutierrez, Microsoft's corporate vice president and deputy general counsel of intellectual property and licensing, Gutierrez said, "We have a history of licensing the patents in this case through patent cross licensing agreements with other leaders in the car navigation space, including Kenwood, Alpine and Pioneer, and through our FAT LFN (File Allocation Table/Long File Name) patent licensing program, where we have 18 licensees to date." This is being done under Microsoft's FAT LFN File System Licensing Program.

Am I reading this right?

https://patents.google.com/patent/US5579517?oq=5%2c579%2c517

It appears that the patent actually expired today ?!? Or is that just Google being clever enough to say that "on this day the status is expired" ??

Because of the patent thing I have deliberately avoided ever getting involved in LFN. Everything I have done in FAT was done with 8.3 so I'm afraid you are on your own. Except to make the repeated point that FatGen103 is the "law". As long as you adhere to what it dictates you will create a FAT compatible system.

Obviously one way to do this also is to try and create whatever it is you are trying to create in both MCU and also either Windows/DOS or Linux/vfat then compare the MCU created data to the other. Anything different is wrong.

Isn't that backward? You design the API first the fill in the implementation.

It's not a very professional approach. Bad habits can become very hard to shake. :-0

Be sure to include this:

For the love and honour of God don't tell them...