On 02/15/06 20:34, dean gaudet wrote:
>
>what you really want is something akin to rsync -c ... which forces
>checksumming of every file, regardless of mtime/size.
>
>
Well, that's basicly what my --checksum-diffs suggestion, which I
suggested in that feature request in october, would do. Calcu
On Mon, 13 Feb 2006, Wiebe Cazemier wrote:
> Something _has_ to be devised to detect changes in files properly, to
> avoid files not being backed up. Perhaps you could try to implement an
> option for ctime checking, and possibly discover again why that's not
> possible. If it _is_ impossible, my
(feature-discussion summary at the end of this mail)
On 02/13/06 21:30, dave kempe wrote:
>
> I think I misread your request. I believe the current method to work
> with changing files during the backup is to take an LVM snapshot. Is
> that going to be possible for you?
I think there still is so
Wiebe Cazemier wrote:
I've read the man page of the development version. The feature I'm
talking about is not present yet.
I think I misread your request. I believe the current method to work
with changing files during the backup is to take an LVM snapshot. Is
that going to be possible for yo
On 02/11/06 00:29, Wiebe Cazemier wrote:
>
>I have read the changelogs, and can only find mention of compare
>abilities for comparing the archive to the current disk-status. But not
>as a way to detect changes in files while doing a backup. Are you sure
>it's in? If so, I'll try the development ve
On 02/10/06 21:29, dave kempe wrote:
> Wiebe Cazemier wrote:
>
>> I really think this feature should be part of the next stable release,
>> because now I can't fully trust my backup to be accurate.
>>
>
> the feature is in the development version... have you tried it?
I have read the changelogs,
On 02/10/06 18:00, Vadim Kouzmine wrote:
>
>I did the same and mtime has changed for me:
>
>dd if=/dev/urandom of=a count=1
>dd if=/dev/urandom of=b count=1
>
>stat a b
> File: `a'
> Size: 512 Blocks: 8 IO Block: 131072 regular file
>Device: 806h/2054d Inode: 2094563
(this is a reply to a message sent to me, but not the list. Press
"reply-all", Gregory :) )
On 02/10/06 19:14, Gregory Benjamin wrote:
>A good argument in favor of this is the case where a hacker
>replaces files on a machine with altered ones that have the
>been fixed to appear to have the same m
Wiebe Cazemier wrote:
I really think this feature should be part of the next stable release,
because now I can't fully trust my backup to be accurate.
the feature is in the development version... have you tried it?
On a sidenote, the wiki at
http://rdiff-backup.solutionsfirst.com.au/?Sugges
On Fri, 2006-02-10 at 15:53 +0100, Wiebe Cazemier wrote:
> Ben,
>
> A while back I suggested a feature to include hash-checks to determine
> if files have changed or not, instead of the mtimes+size combo. I trust
> you remember. I've been away from the list a while, and I see there has
> been a po
Ben,
A while back I suggested a feature to include hash-checks to determine
if files have changed or not, instead of the mtimes+size combo. I trust
you remember. I've been away from the list a while, and I see there has
been a poll. I didn't see this feature in the poll, but I'd like to
emphasise
11 matches
Mail list logo
