> I would find this extremely useful myself -- though it can be simulated > by getting a list of increments, backtracking through it to find the > 30th (should it exist), and then calling remove-older-than with that > date. Much easier to have a remove-more-than option, though, I agree.
As has been pointed out (see previous post), this behavior turned out to exist. > Do you think it would make sense to define behaviour for when both > remove-more-than and remove-older-than are used? It otherwise would be > ambiguous as to whether such indicates one wishes to remove anything > that matches *both* criteria, or anything that matches *either* > criteria. Personally, I think the former is more useful -- removing > anything that matches *either* could be done with two separate runs, > whereas removing anything that matches *both* couldn't. I fully agree, and that is something that (unless I have missed something *again*) is not currently supported. It is a particularly useful criteria, because it will allow one to have a guaranteed minimum retention period while still allowing for additional history in cases where there is not much activity (or the reverse, if there is a lot of activity and rdiff-backup is for some reason run very often). -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org _______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
