add keep_days to prune old originals from .processed/ - #17
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #12.
.processed/archives every original recording forever right now, with no cleanup mechanism at all.keep_daysdeletes originals once they're this many days old;0(the default) keeps the current behavior exactly.Went through an adversarial pass before opening this, since the failure mode of a prune feature is silently destroying someone's original recordings. Two real bugs came out of that and are fixed here, not left as follow-ups:
keep_days(roughly 15+ digits) overflowed the cutoff arithmetic and wrapped it into the future, which pruned everything in.processed/, including a file archived in the same run. Fixed with a 3650-day cap, matching howfpsis already capped. A plain<= 3650check on its own turned out to have the same hole: a long enough digit string gets truncated by zsh's arithmetic before the comparison runs, so the value is bounded by digit count first, before any arithmetic touches it.rm -fon a locked or permission-denied file still failed, but the log said "pruned" regardless, since the log line was written before the removal was attempted. Now it's written only oncerm -factually succeeds.Also fixed along the way:
mvpreserves a file's original mtime on the same volume, so an old recording dropped in and archived today would have been pruned in that same run, before ever sitting in.processed/for the length of timekeep_daysimplies. The archive step now stamps the file with today's date.Two low-severity gaps found in the same pass are filed separately rather than fixed here: #15 (symlinks in
.processed/are never pruned, no data-loss risk either way) and #16 (pruning a large one-time backlog is slow, correctness is fine). A third, a literal newline inside a filename splitting a log line, isn't realistic for anything a screen recorder actually produces and isn't tracked separately.104 tests passing (was 100 on main),
shfmtclean, smoke-tested against a live install.