Bug: The files API is returning all files on SD card

When I call (via GET) http://octopi.local/api/files/local, it works as expected.

However, if I call http://octopi.local/api/files/sdcard (or http://octopi.local/api/files/sdcard?recursive=false), I'm witnessing three bugs:

  1. deleted files (files staring with ".") and deleted folders (folders starting with ".") are returned.
    expected: I expected the API to return only available, non-deleted files.

  2. even though I'm calling the file API w/o recursive=true, my root-level call (whether its http://octopi.local/api/files/sdcard or http://octopi.local/api/files/sdcard?recursive=false) returns all files
    expected: I expected only the files and folders at the specified directory to be returned.

  3. The names are munged. For example, a file with the name of "xyz-half-speed-perimeters.gcode" is being returned as "xyz-ha~2.gcode"
    expected: I was expecting the full name to be returned.

If this truly is a bug and not what is supposed to happen I think it would behoove you to open an issue on github repo, by clicking here and providing all the requested information in its entirety.

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.

1 Like

depends on the firmware but yeah by default it's 8.3 format.

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.

1 Like

@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.

Thanks again for the help!



Open a doc request on the repo, I'll see if I can take care of it. Give a decent explanation so I remember why it's there :slightly_smiling_face:.

1 Like