Gcode filenames with double quotes treated incorrectly

[jacopotediosi]

The problem

I have encountered some weird behavior regarding gcodes with filenames containing double quotes. The bug does not occur with single quotes.

Steps to reproduce:

• upload a foo.gcode file
• trying to rename it to foo".gcode, the API responds with "HTTP 409 - File or folder does already exist"
• trying to rename it to bar".gcode, the rename succeeds
• the filename bar".gcode now appears correctly in both the file sidebar and the new filemanager. Trying to rename or delete it, the dialogs show the name without the quotes:

Did the issue persist even in safe mode?

Yes, it did persist

If you could not test in safe mode, please state why ("currently printing" is NOT an excuse!)

No response

Version of OctoPrint

1.11.1

Operating system running OctoPrint

Arch Linux

Browser and version of browser, operating system running browser

No response

Printer model & used firmware incl. version

No response

Checklist of files to include below

• [x] Systeminfo Bundle (always include!)
• [ ] Contents of the JavaScript browser console (always include in cases of issues with the user interface)
• [ ] Screenshots and/or videos showing the problem (always include in case of issues with the user interface)
• [ ] GCODE file with which to reproduce (always include in case of issues with GCODE analysis or printing behaviour)

Additional information & file uploads

Python 3.13.3

octoprint-systeminfo-20250528102849.zip[^bundle1]

[^bundle1]: octoprint-systeminfo-20250528102849.zip (bundleviewer) (download) OctoPrint: 1.11.1 Python: 3.13.3 OS: Linux-6.12.29-1-lts-x86_64-with-glibc2.41 Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36

[foosel]

So, the reason is that the sanitized version of foo".gcode is foo.gcode:

❯ python
Python 3.12.10 (main, Apr  9 2025, 04:03:51) [Clang 20.1.0 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pathvalidate import sanitize_filename
>>> sanitize_filename('foo".gcode')
'foo.gcode'

which means that foo".gcode and foo.gcode are the same name but not bar".gcode (which is actually saved as bar.gcode on the file system).

OctoPrint shows you both the original name and the internal name on the file system:

So what you ran into here is not a bug per se, but definitely a UX issue introduced by allowing a file to show its original name as the display name, instead of inforcing the internal name. I'm currently unsure on whether I want to change this as if I remember correctly that was actually a feature request at some point, but what I CAN change is the behaviour of the rename dialog, to make situations like this one more clear. Scheduling this for 1.12.0, with an option to port it back to a later bugfix release than 1.11.2.

As a side note, I'm rather surprised to see " being removed from the name, as on first look at the implementation of pathvalidate.sanitize_filename, it should only be removing that under Windows.

[foosel]

As a side note, I'm rather surprised to see " being removed from the name, as on first look at the implementation of pathvalidate.sanitize_filename, it should only be removing that under Windows.

For the record, universal sanitization leads to using the windows related things, so that's as it should be.