GCode Zip-Files in Filemanager

currently my RasPi is running out of filespace, so I thought I can enhance my DeleteMoveAfterPrint-Plugin with a Zip-Feature.
Instead of just moving files to an archive-folder, the gcode should also be zipped.
But if I want to rePrint the file, the filemanager should also be able to select/read the zip-file.

I looked into the github-issues, but couldn't find any request about that kind of feature.

Is there a Plugin for supporting Zip-Files (one zip include one gcode)?

What is the best strategy to implement such plugin?


What you could do is to ghost all the files in the uploads folder with an ~/.octoprint/zipped/ version on a one-for-one basis then replace the originals with a zero-byte sized version back in the uploads folder. When the user selects the file again you can unzip it back to the original location. File finished? Zip it again and knock it back to zero.

This seems to allow the native analysis-on-upload to work as well as to preserve the file history in the metadata.

1 Like

Wow, what a tricky solution!

I will think about this approach and do more research about what octoprint hooks I need for the solution.


I haven't seen a zipped archive approach, but my OctoPrint-UltimakerFormatPackage plugin has some of the zip integrations you're looking for...it extracts from an uploaded file.

Hi @jneilliii
Thx for sharing! That information is really helpful!

Now I have an other question:

  • How is the "FileSelected Event-Order"?

Approach from @OutsourcedGuru: Zero byte file is available via filemanager, file is selected, "new" Zip-Filemanager-Plugin listen for selected file event and extract/move the file, so that the "printer" could process the gcode.
BUT some other plugins also listening to "file selected" and sometimes these plugins reads/modifies the gcode.
I think the Zip-Code copy/extract thing needs to be executed first and then the other plugins could process the gcode. How could this implemented?

Any ideas?

I'm not sure on the order of event firing between plugins. That's probably more of a @foosel question. I'm using the upload hooks on a specific filetype, so didn't have to concern myself with that.

["modifies"] Ye gods... I was unaware of this. (Not sure if I'm a fan of this.)

How about this?

That does look promising, but I don't think @OllisGit is looking into hooks, rather monitoring the event fileSelected. I don't think there is execution order on those, but I might be wrong.

It could then be alphabetical. If you review the order of the bundled third-party plugins' code, I would guess that this is the case. You could name it ZZTopFiles. ha

Hooks :wink:


1 Like

You're hilarious, dude !!!

If I start implementing a plugin the name will be ZZTopFiles-Plugin ...maybe with a small footnote :wink:

one thing to keep in mind, as it zips the file, it creates a temporary file that is the size of the original. it deletes it and the original after the zip is complete