Inadequate error checking in rsync 2.5.5

[jw schultz]

On Thu, Aug 14, 2003 at 11:46:51PM -0700, cbarratt at users.sourceforge.net wrote:
> jw schultz writes:
> 
> > I've had a chance to think on it.  Attached is a patch that
> > allows unmap_file() to report the first read error that
> > map_ptr found.  The behaviour is the same.  I doubt this will
> > apply against anything but CVS HEAD as of now.
> > 
> > This should probably use FERROR instead of FINFO so that a
> > partial transfer is reported.
> > 
> > Any thoughts guys?
> 
> I haven't had a chance to try the patch, but it looks good.
> I strongly support a patch like this that allows errors to be
> reported to the client.
> 
> I just wanted to mention that this is a very important issue for rsync
> on WinXX platforms. Locking is enforced.  So open() will succeed, but
> read() can fail on parts or all of the file.  Examples include Microsoft
> Outlook (.pst) files, and likely any data files behind databases (SQL,
> MS exchange etc). All these files will rsync without errors, but the
> resulting file will have some or all portions of the file set to 0x0.

This is turning out to be quite a common case to be just
ignoring it and zero filling destination files.
	SMB misconfig
	NFS with UID mapping errors
	file truncation
	Windows mandatory locks.
Any others?

If you've a test case, have at it.  I'd suggest changing
the FINFO to FERROR so you will get the "some files could not
be transferred" warning at the end and an exit status of 23
so a wrapper script can retry or at least look to see what
the cause was.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt