Yes looking at comms.py: OctoPrint is looking for EXTENDED_M20 to decide whether to send the L. Marlin also sends that.
Recv: Cap:EXTENDED_M20:1
It seems Cap:LONG_FILENAME means M33 is supported and OctoPrint ignores it.
The LFN_WRITE capability was merged into the bugfix-2.0.x branch of Marlin in January this year, so it does seem to be new.
I have haven't updated OctoPrint or Marlin for many years until now. I don't understand how a Marlin bugfix branch would have new features in it compared to the last release.
Looking at the code in comms.py my best guess as to why the first M20 doesn't include an L is because the commands are queued, so perhaps the M20 command is built and added to the queue before the preceding M115 results have been parsed and the capability set.
If M20 L sends the list of files with both the short and long names, why do you need M33? You have all the loing names. The only comments I can find for M33 is @foosel saying it doesn't scale as you have to call it for every file.
My only issues are that the first M20 after connection is missing the L parameter and when writing files OctoPrint sends the short name regardless of Recv: Cap:LFN_WRITE:1 which indicates Marlin will accept long names for writes.
On my LulzBot TAZ 6 (with LulzBot's Marlin 2.0.9.0.13 firmware), M20 and M20 L return only the 8.3 filenames but M33 returns the long file name. LulzBot probably doesn't have the right options selected.
OctoPrint reads the results of M33, to update the file list. But it will not send an M33 command for every file in the list from M20, as it would lock up the serial connection for an unspecified length of time. There is however a plugin should you wish for this:
Looks like the release version of Marlin always adds the ??? long filename unless the file has a long filename. I.e. Even files that have short uppercase names that are 8.3 compatible. So the only files that get a correct name are those with long names that have been written directly to the card.
I am surprised I am the only one to notice this. Does nobody else run the release version of Marlin with LONG_FILENAMES enabled?
Long filenames could potentially be problematic with OctoDash too. I think it has it's own clipping of filename that will only show the first x characters and then finish out with ellipses IIRC.
Bug in OctoPrint for initial loading issue based on what I've read here, and potential feature request in OctoDash. The file list in OctoDash will display a lot of characters, but if it does go beyond the length available on screen it will truncate, see below example, 4th file down.
If this picture is of OctoDash then mine doesn't show it like this. It shows it in a 8.3 format. If it would show it like this I would have not mentioned it.
