rsync - Feb 2003 - rsync/cygwin - strange behavior with VFAT-formatted USB-disk

Hi,

we do a nightly backup using rsync (v2.5.6 as server on RedHat 7.3 and rsync
2.5.5 on Windows 2000/Cygwin). The backup media connected to the
Windows-Client is a VFAT-formatted Maxtor USB-Disk.

Everytime I run rsync from the windows-client, the following error occurs:

--- <snip> ---
rsync.exe -avzr --compress --stats --delete --timeout=240 --modify-window=2
rsync@server::development  cygdrive/e/backup/development
.
.
MOD-SR1/common/
MOD-SR1/common/help/
rsync: connection unexpectedly closed (105057 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(150)
.
.
Wise InstallBuilder 8.0X/RUNTIME/DIRECTX5/
Wise InstallBuilder 8.0X/RUNTIME/DIRECTX5/directx/
rsync: connection unexpectedly closed (105057 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(150)
--- <snip> ---

And then rsync stops working. The same error message everytime. But there is
nothing special about the files and the rsync-server is running with
root-permissions.

I guess it has something to do with the with the VFAT-formatted USB-disk -
I've tried the same command with my local NTFS-formatted harddisk as backup
media - and everything works fine!

Any ideas :o( ??

Regards,
Lejf Diecks

Systemtechnik/Entwicklung
----------------------------------------------------------------

ergo!via GmbH
Kieler Innovations- und Technologiezentrum (KITZ)
Schauenburgerstr. 116
D-24118 Kiel

On Wed, Feb 19, 2003 at 11:21:32AM +0100, Lejf Diecks [ergo!via GmbH]
wrote:
> Hi,
> 
> we do a nightly backup using rsync (v2.5.6 as server on RedHat 7.3 and
rsync
> 2.5.5 on Windows 2000/Cygwin). The backup media connected to the
> Windows-Client is a VFAT-formatted Maxtor USB-Disk.
> 
> Everytime I run rsync from the windows-client, the following error occurs:
> 
> --- <snip> ---
> rsync.exe -avzr --compress --stats --delete --timeout=240 --modify-window=2
> rsync@server::development  cygdrive/e/backup/development
> .
> .
> MOD-SR1/common/
> MOD-SR1/common/help/
> rsync: connection unexpectedly closed (105057 bytes read so far)
> rsync error: error in rsync protocol data stream (code 12) at io.c(150)
> .
> .
> Wise InstallBuilder 8.0X/RUNTIME/DIRECTX5/
> Wise InstallBuilder 8.0X/RUNTIME/DIRECTX5/directx/
> rsync: connection unexpectedly closed (105057 bytes read so far)
> rsync error: error in rsync protocol data stream (code 12) at io.c(150)
> --- <snip> ---
> 
> And then rsync stops working. The same error message everytime. But there
is
> nothing special about the files and the rsync-server is running with
> root-permissions.
> 
> I guess it has something to do with the with the VFAT-formatted USB-disk -
> I've tried the same command with my local NTFS-formatted harddisk as
backup
> media - and everything works fine!
> 
> Any ideas :o( ??
I'd start by reccomending that you get both ends of the
connection on version 2.5.6

There are so many problems with USB storage i'm not suprised
you are having problems.  Many of the USB chipsets have
timing problems that would be exacerbated by the load rsync
imposes.  As best i can recall MS-Windows tends to not
report hardware errors so you don't know you have a problem
until the filesystem is thouroghly corrupted or the system
crashes.  I wouldn't be suprised if checkdisk (or whatever
the MS/VFAT equivalent of fsck is) found numerous
consistancy errors.

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

		Remember Cernan and Schmitt

At 11:21 19/02/2003 +0100, you wrote:
>I guess it has something to do with the with the VFAT-formatted USB-disk -
>I've tried the same command with my local NTFS-formatted harddisk as
backup
>media - and everything works fine!
>
>Any ideas :o( ??

It could be a shortfalling of the VFAT filesystem - specifically the way vfat
handles permission and ownership which is greatly inferior to Linux ext2/3 
filesystems.

I used to have a vfat partition on my server back when it was dual boot 
linux/winNT.
It was impossible to change ownership on the vfat volume:-

"chown -R nick.nick *"  would always give
"operation not permitted"

Just a guess.....

hih
nick@nexnix