mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 13:45:32 +02:00
[GH-ISSUE #1008] [Feature]: Purge out old files from file manager #706
Labels
No labels
A1
automated
automated
bug
bug
Closed due to inactivity
contrib
dependencies
dependencies
duplicate
enhancement
feedback
hold
invalid
Notes
P1S
pull-request
security
security
ThumbsUp
user-report
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/bambuddy#706
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @cadtoolbox on GitHub (Apr 17, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1008
Originally assigned to: @maziggy on GitHub.
Problem or Use Case
With lots of users and lots of prints the files can become plentiful making backup and restores take a long time.
Proposed Solution
Add ability for admins to purge out older files that have not been re-printed in X number of days.
Alternatives Considered
No response
Feature Category
File Manager
Priority
Nice to have
Mockups or Examples
No response
Contribution
Checklist
@maziggy commented on GitHub (Apr 22, 2026):
Before I build it, a few questions so it lands the way you actually need:
Manual or scheduled (or both)?
- Manual: an admin "Purge old files" button with a confirmation dialog showing count + disk space to be freed.
- Scheduled: runs daily/weekly in the background, same way the new scheduled local-backup works.
- Both is also fine but adds some UI.
What counts as "old"? Just a day threshold (e.g. "not re-printed in 90 days"), or would you also want per-file-size / total-library-size triggers (e.g. "keep library under 10 GB, drop oldest first")?
Files never printed — some files get uploaded and never printed at all. Should those be included once they cross the age threshold, or left alone?
External files (3MF files linked from a network path rather than stored locally) — I'd skip these since they don't take disk space. Any reason not to?
Safety net — do you want purged files to go to a soft-delete / trash state first for a grace period, or direct hard-delete? Soft-delete is safer but uses the same diskspace until the grace period ends, so it doesn't fully solve the backup-size problem unless the grace period is short.
Per-user vs global — should each user's files be purged independently based on their last-print time, or is this purely an admin-wide operation?
@cadtoolbox commented on GitHub (Apr 22, 2026):
1.) I would probably say manual would be sufficient and the safer route.
2.) If it's manual, maybe allow the admin to pick "Older than XX number of days"
3.) Yes
4.) Agree
5.) A trash bin approach is fine, after X number of days it then deletes.
6.) I say an admin approach, but I don't try to use Bambuddy as a repository, it's a tool to print.
@maziggy commented on GitHub (Apr 23, 2026):
Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you.
Docs -> https://wiki.bambuddy.cool/features/file-manager/?h=purge#purge-old-files-admin
Shipping the File Manager purge + trash bin + auto-purge setting for now. Your original concern — backup/restore size — also applies to the Archive section, which tends to be bigger than the library in my own install. Want me to extend the same treatment (trash + retention + optional auto-purge) to archives?
@cadtoolbox commented on GitHub (Apr 23, 2026):
@maziggy Yes please!
@maziggy commented on GitHub (Apr 23, 2026):
I was afraid of that :)
@maziggy commented on GitHub (Apr 23, 2026):
Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you.
Docs -> https://wiki.bambuddy.cool/features/archiving/?h=purge#enabling-auto-purge
@cadtoolbox commented on GitHub (Apr 27, 2026):
@maziggy Works perfectly!