Previously the date handling expiry logic had a bug where if you had
backups that were a year apart to the day, it wouldn't notice the
difference in year and only notice that the month was the same, and
expire the older one (eg, if you had a backup on 2012-04-01 and
another on 2013-04-01, it'd delete the one from 2012. This commit
makes it compare the full date string instead of just the month, so
that it more robustly keeps older backups.
Code was assuming that you'd run backups hourly, eg, so you'd have
many backups within the last 24 hours. Code assumed that by the time
you found a backup more than 24h old, you'd already have a value for
$prev set. In the event that your most recent backup is more than 24
hours old, $prev would not be set and bash would get an error "unary
operator expected" when it tried to compare the day of the newest
backup to the empty $prev value.
I fix this by setting a default value for $prev, one that cannot be
mistaken for an existing backup because it does not represent a valid
date. This ensures that the most recent backup is correctly preserved
regardless of it's age.
Within 24 hours, all backups are kept. Within 1 month, only the most
recent backup for each day is kept. For all previous backups, only the
most recent of each month is kept.
This is not *quite* the same as Time Machine, but this implementation
is a lot easier to do since it is based on string comparisons of the
dates and doesn't require any "hard" date logic.
Also this commit just 'echo's what will be deleted, and does not
actually delete anything yet because I am still testing it.
Robert Bruce Park