[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] Re: [librsync-devel] librsync: ERROR: (rs_file_
From: |
Ben Escoto |
Subject: |
Re: [rdiff-backup-users] Re: [librsync-devel] librsync: ERROR: (rs_file_copy_cb) seek failed: Invalid argument |
Date: |
Thu, 6 Nov 2003 19:34:30 -0800 |
On Thu, 06 Nov 2003 15:39:50 -0700
Robert Weber <address@hidden> wrote:
> It Failed:
...
> rdiff_backup.librsync.librsyncError: librsync error 100 while in patch
> cycle
>
> But to be absolutely sure, I re-ran the rdiff, but on the original file in
> on the client(rather than copying it to the server first) and lo and
> behold:
...
> librsync: ERROR: (rs_file_copy_cb) seek failed: Invalid argument
> librsync: ERROR: (rs_job_complete) patch job failed: IO error
...
> 1) why does rdiff-backup try to diff-patch a file that is the the same on
> the mirror as it is remotely
Probably rdiff-backup thinks the metadata of the file have changed.
Internally, rdiff-backup uses "diffs" and "patches" at a higher level,
where they include both data and metadata. So a change in either will
produce a diff with both.
It's inefficient, but rdiff-backup doesn't know whether or not a file
has changed. It doesn't compute an SHA hash or anything like that
separately from librsync.
So if you make a file, run rdiff-backup, change the perms of the file,
and run it again, you'll see a .diff.gz increment in the
rdiff-backup-data directory. This stores the old permission
information. Here it isn't really necessary to have any regular data
associated with that file, but the system does avoid special cases.
> 2) how should librsync behave when it patches a file that matches the
> original?
Presumably when asked to produce a delta for such a situation, a very
small "null" delta should be created, that says not to replace any
blocks. Patching with the null delta should produce the original
basis file.
--
Ben Escoto
pgpTDYq45HyQW.pgp
Description: PGP signature