Re: [rdiff-backup-users] feature requests and notes

[Ben Escoto]

On Tue, 28 Oct 2003 07:07:07 -0500
address@hidden (Andrew K. Bressen) wrote:
>  sparse files
>  remove intermediate increments
>  remove enough to finish 
> 
> to the support request system. 
> 
> I classed the latter three as "possibly impractical" because Ben's
> on-list replies made me think that they would be tricky to do.

#2 doesn't seem that bad to me.  #1 I think can be done in most cases
(doesn't rsync do it?) but I don't know how off-hand.  #3 seems
impossible :)

> >>     [s]locate(1) functionality
> >>     md5 sums
> >>     file integrity (tripwire/integrit) functionality
> >>     retrieve increment history of a specific file
> >
> > What do these mean?
> 
> The last, retrieve increment history of a specific file,
> was something mentioned by Keith Edmunds in his list mail of 16-sep-03. 
> 
>  As I read it, he wanted to be able to list all information about a specific
>  file in the backup; ie, something like "ls -ali" output showing all
>  the versions of the file in the archive, so one could see at what point
>  in time a certain problem occurred, and thus figure out which version
>  to retrieve. 
> 
> The second, md5 sums, was from some earlier list discussion about
> using them vs. inodes for change detection. 

The md5 sum thing for detecting moved/duplicate files is complicated,
and may make things slower.  Before someone can even start
implementing it, someone should:

1.  Determine if it would be worth it.  Is the point to save space?
    Are people really short of space nowadays?
2.  Figure out how to store this information in a way compatible with
    the current format (which pairs increment and source files by
    filename).

Because this comes up regularly it would be a good thing to add to the
wiki I think.

> The other two refer to one of my hobby-horses, which is that backups, 
> integrity/intrusion checking (tripwire, integrit, etc.), 
> fast locate apps (gnu locate, slocate, etc.) and 
> duplicate file finding apps (fdupes and many others) 
> all end up needing and using the same info 
> (basically, the contents of the metadata file plus some hashes and atime), 
> so making one app or set of related apps do all of these saves cycles
> and overall complexity. I mentioned this on-list a while ago.

Yes I see the duplication of effort but not how to eliminate it.  What
do you have in mind?  Wouldn't trying to put this into rdiff-backup
just make things more complicated and error-prone?


-- 
Ben Escoto

pgpZzx2ce0Jzg.pgp
Description: PGP signature