Marlin: sd commands: improve long file name support in M28 (and M23)

[zachwelch]

Description

The M28 (open SD file for write) and M23 (select SD file) commands fail when given long file names.

The Marlin source code vaguely looks like it should support this use case already (or could support it with fairly little effort), but my testing seems to show that anything other than an 8.3 name causes the open to fail.

Steps to Reproduce

1. Load up a firmware built with SDSUPPORT and LONG_FILENAME_HOST_SUPPORT
2. Send it M28/foo.gcode or M28/something.gcode

Expected behavior:

  echo:Now fresh file: /something.gco
  Writing to file: /something.gco

Actual behavior:

  echo:Now fresh file: /something.gco
  open failed, File: something.gco.

Additional Information

The M28 command can be given an 8.3 compliant name to work past its initial shortcoming, but that workaround demonstrates additional missing long name support. For example, M28/foo.gco will work; M20 will display that new file in its standard normal form (FOO.GCO), indicating its primary directory entry took that expected form. A subsequent M33FOO.GCO produces /??? in reply, indicating that the new file was not also given a directory entry to hold the long name that contains the case.

That may be a completely separate bug, but these issues both need to be fixed to make M28 work properly with long names. I have been investigating the code to find the root of these problems, but someone more familiar with it might be able to help direct me to the right spots.

[thinkyhead]

Starting a print using the long filename will not be supported, as it is not necessary. SD card-reader code will continue to be patched up as new issues are found.

[radex]

Starting a print using the long filename will not be supported, as it is not necessary.

@thinkyhead Why not? It would be optionally compiled, under LONG_FILENAME_HOST_SUPPORT, of course, but if an option was added to M20 to print human-friendly full filenames (as I would like to do - via #define flag and/or parameter to M20), it would make it easier for hosts to just pass that filename as param to M28 and the like

[gruvin]

Why is this even still an issue? Ancient 8.3 filenames died out before the dinosaurs. Why not just fix the problem at its source? The entire phrase, "human-friendly full filenames" is in itself ridiculous. Humans WROTE THE CODE, for goodness sakes. The FAT filesystem is the ONLY filesystem that ever did stupid, "unfriendly" 8.3 names in the first place, far as I can recall. Why, pray tell, are we being bound by such nonsense? Let's just pretend 8.3 names were a mistake from a bygone era and forget they're even an option.

It would be optionally compiled, under LONG_FILENAME_HOST_SUPPORT

Nope. Let's not. Let's have the ONLY option be to have filenames the way they always should have been.

Marlin is the lowest level of the software stack. It should lead the way, not hold the upper layers in shackles. If some crazy host software cannot handle normal filenames (seriously?) then let them write code to go back in time.

[gjpc]

The FAT filesystem is the ONLY filesystem that ever did stupid, "unfriendly" 8.3 names in the first place, far as I can recall. Why, pray tell, are we being bound by such nonsense?

@gruvin Not quite. CPM, HP DOS, RSX11, DEC DOS, RSTS are a few of the 8.3 file systems I can remember off the top of my head.

I guess you never had to contend with a total 8KB core memory system where 3 characters of every file name were stuffed into a RADIX50 16bit word :)

Sing along:
_Every byte is sacred
Every byte is great
If a byte is wasted
Core will be obsessed_

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.