Please describe what you are doing to trigger the bug:
Running scheduled prune jobs from duplicacy web UI,
Please describe what you expect to happen (but doesn’t):
Expect files in .duplicacy-web/repositories/all/.duplicacy/logs to be periodically pruned as the log files in .duplicacy-web/logs are.
Please describe what actually happens (the wrong behaviour):
Found 5,130 files named prune-log-20220605-000830 through prune-log-20250601-020041.
duplicacy-web is an all-but-abandoned, broken hack-job GUI stapled on top of a very good CLI tool as an afterthought. My advice would be to remove these logs manually, and then maybe create a script to clear out the logs periodically. Maybe integrate that script into one of the duplicacy-web scheduled jobs.
Don’t expect it to be fixed anytime soon. Last update duplicacy-web got was 2 years ago.
Historically, log pruning and rotation is expected to be handled centrally by system utilities, like newsyslog and derivatives, not applications generating the logs.
I’m not sure why and whether web-ui prunes own logs.
Separately, i would archive and keep all logs, and especially prune logs, indefinitely. Storage is cheap and if something does wrong logs are the only artifacts that will help you get to the root case.
Never having properly used the cli binary full-time nor in production except for brief forays and testing purposes, does the cli keep its logs permanently? How does it manage log rotation? Are they saved to /var/log?
Unfortunately, in the age of AI, this is sadly becoming the case less and less.