[rdiff-backup-users] feature requests and notes

[Andrew K. Bressen]

Hi--

I have some feature request/suggestions:

(1) python errors are wonderfully informative compared to most
environments these days, but not so easy to automatically parse.
If rdiff-backup could spit some indicator at the beginning and
end of each error stack, that would make writing log parsers
much easier. I usually run at -v6; I don't know if running at
a lower level would be more easily parseable. I have found this
to be a useful level for diagnostics/bug reporting. 

Actually, it comes to mind that perhaps outputting the log level
of each message at the start of the line would be useful, so I could
grep out the level one or two output to read and keep the lower
level stuff in case it is needed later. 

(2) from reading the list, it seems that sometimes (as when a file
in the backup dir is inadvertantly deleted) users may have to 
manually dink with the metadata. It'd be cool if there were tools
to do this programmatically, such as options to delete the latest 
or all versions of a file from the archive, or to sync the metadata 
to the archive contents.

I'm unclear on if --check-destination-dir does anything besides 
back out the failed increment attempt. 

(3) in re space management by number of backup cycles instead of
by dates, Ben said:

  "Yes, it's a good idea.  How about if a new time specification was
   allowed, so that '--remove-older-than 4B' would remove everything
   older than the 4th Backup session?  It could be useful when restoring
   also, e.g. '--restore-as-of 2B'."

I thought of a new failure scenario that might complicate this syntax. 
If my daily backup scripts do a --remove-older-than 7D and something
goes wrong with backing up, but not the remove, for 8 days, I could be
in trouble. Ideally, a way to tell --remove-older-than to retain a
certain minimum number of copies would be a safety, and I don't think
the above syntax quite allows for that. Similarly, if one has been 
doing lots of tests and reruns one day, perhaps one would want to make sure
to have several days worth of backups around. 

Perhaps a --retain-at-least that also took 
<number> smhDWMY and <number> B args?

(4) is the TODO list up somewhere accessible? 
  (grep grep) here's what I have noted:

  requests that have been ack'd as feasible/reasonable:
    dry-run option
    maybe a full-compare integrity check

  requests that may not be practical:
    "There is no option to remove just the number of increments that 
       would let you complete the current backup"  
    removing an intermediate increment
    [s]locate(1) functionality
    md5 sums
    file integrity (tripwire/integrit) functionality
    decent sparse file handling (seems to be nonportable)
    retrieve increment history of a specific file

  stuff with non-rdiff-backup dependencies:
    mac os x does not support python acl calls 
      (I'm unclear on the real-world impact of this; 
       do any mac fs' support acls?)
    situation on windows and samba time granularity unclear
    situation on NFS unclear

(5) Ben, a while back you said that a file mv was handled as a delete and 
an add of the whole file. But I noticed in some later mail you talked about
tracking changes via inodes vs. md5 sums. Does this mean that at some
point one or both will be implemented? Does that in turn mean that 
mv's could be detected?

(6) Documentation
the man page linked from http://rdiff-backup.stanford.edu/docs.html
  doesn't say what version it's for or when it was made. 
http://rdiff-backup.stanford.edu/format.html
  claims to be current for 0.6, and I know metadata handling
  has changed dramatically since then... 

  --akb