Organize STL, 3MF, and G-code files

A 3D-printing folder tends to mix downloaded meshes, slicer projects, exported G-code, screenshots, and ZIP files. The first useful change is to separate those jobs. You can do that with ordinary folders before installing anything else.

Separate the three kinds of files

Treat these as different file roles:

• Source geometry includes STL, OBJ, STEP, STP, and design-oriented 3MF files. Keep the original download or export.
• Slicer projects are commonly 3MF files with plate layout and settings. Keep the useful project state when reproducing the plate would take work.
• G-code is printer, material, nozzle, and profile specific. Keep the revisions that explain a decision or have a print result.

The 3MF extension can represent source geometry or a slicer project, so the folder and filename must provide the missing context. A source/, project/, and gcode/ layout inside an important model folder is enough.

Folder structure: shallow, by subject

Use a shallow hierarchy based on project or purpose, such as props/helmets/mando. Do not add a new directory level for material, nozzle, support requirement, designer, and every other property. A file has one path, while those properties can change or overlap.

Filenames are not a database

bracket_016_15pct_brim_FINAL_GOOD_v3.gcode tries to carry a database in its name. Keep filenames short enough to read on the printer. Model name, a meaningful revision label, and the target machine are usually enough.

Common slicers embed many settings in G-code comments. A tool can recover layer height, material, temperatures, nozzle size, and estimates later. The reason for a change still needs a note, because the file cannot explain why you added the brim.

Deduplicate by content, not by name

Compare content hashes before deleting apparent duplicates. Tools such as fdupes, rmlint, and jdupes can do this on a normal filesystem. Review the paths first. An identical copy inside a packaged project may be intentional even if it uses extra disk space.

Track which G-code actually worked

After a print, record the exact G-code filename and the result. A small Markdown file next to the project works. Include only details you will use later: success or failure, the important change, material, and any machine-specific warning.

This is the part most likely to decay. Write the note while removing the part from the bed, not three weeks later.

Where a file manager earns its keep

PrintStash automates the parts that are tedious to maintain by hand:

• Content hashing detects identical files during ingest.
• Supported G-code metadata becomes structured fields and filters.
• G-code revisions stay attached to the source model with labels, notes, outcomes, and one recommended choice.
• Successful connected-printer jobs can mark an eligible revision known good.
• A shared volume can index the existing directory tree in place.

The manual system remains valid. Use it if the collection is small and the notes stay current. Install a library when maintaining the index by hand becomes more work than running the service. The large-library guide covers an existing archive, while the getting-started guide covers a new Docker Compose setup.