Sync a printer's files with a central library

A sync tells you which files on each machine the library already knows about. What it cannot fix is the workflow that put different files on different machines in the first place: at three or more printers, a central library with a fleet queue replaces the per-machine copy loop with enqueue-once routing. This guide covers what the sync does and how the matching works.

The G-code sitting on a printer accumulates the way a downloads folder does: files you uploaded twice, files from a slicer you no longer use, and a benchy.gcode that could be from any of the last six months. A library can index that list and tell you which of those files it recognizes, which is genuinely useful. What it does not do is pull the files back into the library.

Worth being precise about, because “sync” implies a two way file transfer and this is not one. PrintStash reads the printer’s file list, correlates each entry to a revision it already has, and marks the rest as external. The bytes stay on the printer.

What a sync run does

Ask a printer to sync and PrintStash fetches its remote G-code inventory, then for each remote filename records the size, modification time, and the library revision it belongs to, if it can work that out. The result is a per-printer file list where each row is either linked to a revision in your library or labeled external.

Inventory works on Moonraker, PrusaLink, and OctoPrint. Bambu LAN exposes no file inventory, so there is nothing to sync there, and Elegoo Centauri exposes none either, although beta uploads can put files on it. On the providers that support it, you can also delete remote files from PrintStash, which is the practical way to clear a full SD card without opening three web interfaces.

How a remote file gets matched

The matching runs in order, and the first hit wins.

The reliable one is a marker embedded in the filename. When PrintStash uploads a revision, it renames the file on the printer to something like voron_panel__vault-f412-9c1f0ab3d5e2.gcode, where the trailing segment carries the file’s id and the first twelve characters of its sha256. On the next sync the marker is read back and verified against the stored hash before it is trusted, so a file whose name was copied onto different content does not match.

If there is no marker, PrintStash checks its own upload history for that printer and that remote filename. After that it falls back to two guesses: an exact match on the basename against a live G-code file in the library, then an exact match on file size. Anything left over is external.

Those last two are heuristics and worth treating as such. Two different slices exported as benchy.gcode will match the most recently uploaded one, and size matching is a coincidence detector, not a hash. If accurate correlation matters to you, upload from the library so the marker is there.

When files disappear from the printer

A sync also notices what is gone. A row that was linked to a library revision is kept and flagged as missing rather than deleted, because the fact that a known print used to be on that machine is part of its history. Unmatched external rows carry no history worth keeping, so they are dropped outright. The visible file list shows only what is currently on the machine.

Getting a stray file into the library

There is no button that imports a file’s bytes from a printer, and this is the honest gap in the workflow. A file that exists only on the printer’s SD card has to come back the way it went out: download it from Mainsail, Fluidd, or OctoPrint, then upload it into the library and attach it to its model as a revision. Job records are a different matter on Moonraker printers, whose print history can be imported into a matched model; syncing an SD card with a central library covers what that pull includes and where it stops.

That is tedious enough that the better answer is usually to stop creating strays. Send prints from the library rather than from the slicer’s direct upload, or let the OrcaSlicer hook catch exports on their way out, and the printer’s SD card becomes a cache rather than an archive. The files worth keeping are then already in the library, with their parsed settings and their outcomes attached.

A cleanup pass that works

1. Sync the printer’s inventory.
2. Look at the external rows. Those are the files the library does not have.
3. Download the few that matter, upload them as revisions of the right model, and label them while you still remember what they were.
4. Delete the rest from the printer.
5. From then on, send from the library so new files carry the marker and match on sight.

Doing that once per machine takes a few minutes and makes the next sync readable, which is the whole point.

Questions that come up

Does syncing copy the printer’s files into the library?

No. The sync reads the printer’s file list and correlates it against revisions you already have, recording each remote file’s name, size, modification time, and the revision it belongs to. No bytes move from the printer to the library. Getting a printer-only file into the library means downloading it from the printer’s own interface, such as Mainsail, Fluidd, or OctoPrint, and uploading it as a revision. There is no action that imports a file’s bytes from a printer in the shipped release; print-history import on Moonraker brings over job records rather than files.

How does PrintStash know which library revision a printer file is?

Four ways, in priority order. Files uploaded from the library carry a marker in their remote filename holding the revision id and a hash prefix, which is verified against the stored hash before it is trusted. Failing that, PrintStash checks its upload history for that printer and filename. Then it tries an exact filename match against a live G-code file, and finally an exact file size match. Anything that matches none of those is listed as external. The marker is the only one of the four that cannot be fooled by a coincidence, which is a reason to upload from the library rather than from the slicer.

Which printers support file inventory?

Moonraker, PrusaLink, and OctoPrint expose a remote file list that PrintStash can read and prune. Bambu Lab printers in LAN mode accept uploads and an opt-in start but expose no inventory, so PrintStash cannot tell you what is on the machine. Elegoo Centauri exposes no inventory either, so the same applies, though beta uploads can send files to it. The compatibility matrix is the current per-provider list.

What happens to the record when I delete a file from the printer?

If that file was linked to a library revision, the entry is kept and flagged as missing, so the history that a specific revision once lived on that machine survives the cleanup. If it was an unmatched external file, the row is removed, because there is nothing to preserve. Either way the current file list only shows what is actually on the printer right now.

Should I keep files on the printer at all?

Keep what you are printing this week and let the library be the archive. A printer’s storage is a cache with no metadata, no version history, and no backup, and the first sign of trouble is usually a full SD card during a long print. The library keeps the slice, its parsed settings, its outcome, and its print history, and pushing a file back to the machine takes seconds.

Sources

• PrintStash printers guide and the compatibility matrix for which providers expose a remote file inventory in the shipped release.
• Moonraker’s file manager API for the underlying file listing on Klipper machines. Checked August 12, 2026.

For the send side of the same loop, connecting a Klipper printer through Moonraker covers uploads and job control, and managing a mixed fleet covers what changes when the machines do not all speak the same protocol.