Relative to this specific part, that's a firmware related issue. The firmware only returns the names in 8.3 format if I'm not mistaken, so there's nothing the API can really do here to fix that I don't think.
All of the factors you have referenced heavily depend on the response from the firmware, if the firmware presents all of these files then so should OctoPrint. Files beginning with a dot are not a necessarily deleted, it's a valid filename and often used to denote hidden files - but doesn't have to be.
If you do perceive this to be a bug, providing the firmware's response is a necessity so make sure you enable serial logging.
@jneilliii, @PrintedWeezl, and @Charlie_Powell, thanks for replying and thanks for the info. I don't know OctoPrint's internals and didn't know how it was going about getting the data (the files and directories) from the SD card, but from your posts I was able to gain some insight into what's going on (and later ran across this thread - https://github.com/OctoPrint/OctoPrint/issues/1600). I agree with each of you - it's a bug, but due to the limitations of the printer's firmware, it's a bug in Marlin, not OctoPrint.
I have one suggestion, and that is, in the online documentation for the SDK, in the docs for the files API (https://docs.octoprint.org/en/master/api/files.html#retrieve-files-from-specific-location), it would be nice if the limitations of using location=sdcard were mentioned and documented. Since it's a single API that's used for retrieving files from either OctoPrint or the SD card, and since using location=local works great, it comes across looking like there's a bug in OctoPrint when location=sdcard is used, and documenting this might be helpful to others.
But you have to love the snark in the github thread - complaining about M33 and dealing with the issue being 'time consuming' and resource intensive. This from guys that build their own cPU/resource consuming python server into a single-device-limited print server rather than making it capable of being plugged into something like lighttpd so if you need to run other webservices, now you need TWO servers running on your wee wittle raspberry pi. BRILLIANT!
I don't frankly care if it's long files or short - the issue I'm running into is that I cannot seem to do anything with the files. It won't let me print them, won't let me move them, won't let me delete them, won't let me rename them. Any suggestions? (this behavior is specific to files on my sdcard that are in sub-folders - they show as something like FILES/MYFILE~01.GCO
I don't like your tone. You know that this is isn't some kind of big company project and "the guys" aka @foosel is reading your posts, right?
Constructive criticism is one thing but bad mouthing is something I don't tolerate here.
Btw everyone is free to choose if he/she wants to use the software and on what platform they want to use it.
If you think "your wee wittle raspberry pi" can't handle it, let it run on your 64 core epic server and if you can't stand the way the software is designed, just don't use it.
Great article. It happens in IT support and many, many other fields too.
I could not guess how many times have I been hit with the "it only takes 20 cents of plastic filament, and so I shouldn't have to pay for the 6 hours of design and test prints, nor the changes when I change my design half way through".
Anyone who reads that article and disagrees, expects more or complains should immediately check this reddit to see if they recognize themselves....