On Tue, May 11, 2004 at 09:42:15PM -0400, Carson Gaspar wrote:
> Yes - rsync should _not_ use known-bad copies of files unless --partial has
> been specified.
I'd have to agree with Carson 100%. Of the files that appear on the
destination, I'd expect them all to be 100% accurate or fail to get
c
--On Tuesday, May 11, 2004 13:39:24 -0700 Wayne Davison <[EMAIL PROTECTED]>
wrote:
What do you think? Rsync has always moved a finished file into place,
even if it fails the full-file checksum. I'm wondering if this is
really a good idea. Perhaps that should only occur if the --partial
flag
On Tue, May 11, 2004 at 01:39:24PM -0700, Wayne Davison wrote:
> It's pretty easy to at least fix this file-is-up-to-date deception.
While this fix may be useful to some people, I'd much rather wait to
see a real fix such that read errors on the sending side doesn't result
in a corrupt file on the
On Mon, May 10, 2004 at 02:45:15PM -0700, Todd Stansell wrote:
> Subsequent rsyncs will succeed without any errors as long as the -c
> option isn't used. You'd never know the file was corrupted, since the
> size and timestamp are both correct on the destination file.
It's pretty easy to at least
On Mon, May 10, 2004 at 02:45:15PM -0700, Todd Stansell wrote:
> 2.6.2 now produces an error message, but still also produces the
> corrupted destination file.
Yes, starting with 2.6.0 we at least get an error message that something
went wrong. However, it would be much better if the receiver did
I've run into a bug in the IO handling when reading a file. Suppose I
have a file that lives on an NFS filesystem. That filesystem is NOT
being exported with auth=0 permissions. So, if I try to access a file
as root, it successfully opens the file, but subsequent reads fail with
EACCES. This pr
