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

Development
#1

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.

#2

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.

#3

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
#4

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

#5

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
#6

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

Jeff

2 Likes
#7

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