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
8

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!

1 Like
9

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

1 Like
10

@treii28 What? Open a new thread.

11

Sounds like someone needs to read and understand this:

2 Likes
12

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.

5 Likes
13

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