several errors with irregular pathnames
Eric van Blokland
eric at footsteps.nl
Mon Nov 15 13:28:16 GMT 2004
I've written a GUI for using rsync on windows machines for third-party
use. The project has reached a beta state and is now being tested in
live situations. However, during these tests, I've encountered some odd
behavior with specific pathnames.
For the record: I'm currently using a cygwin distribution which includes
rsync 2.6.3 to run rsync on Windows machines. The remote server is
running a rsync 2.6.3 deamon through xinetd on a Fedora Core 2 machine.
Also for the record: the behavior occurs only when transferring
(downloading) from the server to the client (Linux to Windows) never
when transferring (uploading) from the client to the server.
When I start rsync using the following command:
rsync.exe --archive --delete --exclude="~$*" --exclude="*.bak" -vvv
"module at server::module/1/1100190900/d/Users Shared Folders/DOC
VdeM/Bestuur VdeM/" "/cygdrive/c/temp/"
rsync dies while building the file list:
overflow: flags=0x38 l1=180 l2=84 lastname=1/1099999800/current/d/Users
Shared Folders/Gebruikers/USERS VdeM total oude server/Archief
ex-medewerkers/Jeffrey Colley/VdeMsite/Kopie van
ERROR: buffer overflow in receive_file_entry
rsync error: error allocating core memory buffers (code 22) at
line=126): about to call exit(22)
While this error should get some attention by my opinion, this error is
however, probably the result from another error:
I am trying to transfer from this path:
the error generated, occurs in this path:
Additionally, the server gives a "Connection Reset". Prior to this, some
correct "permission denied" errors can be found.
Although I don't know why this error occurs, I might have an
I stumbled on this problem while trying the following:
rsync.exe --archive --exclude="~$*" --exclude="*.bak" -v
"module at server::module/1/1100190900/d/Users Shared Folders/DOC Vde
The client dies with the comment "nothing to do" but believe me, the
file is there. The rsync server log tells a complete different story:
2004/11/15 13:25:14  link_stat "1/1100190900/d/Users Shared
Folders/DOC Vde M/Bestuur" (in module) failed: No such file or directory
2004/11/15 13:25:14  link_stat "Bestuur
2004/03-11-04/B-BV-v-041103-verslag-bestuursvergadering.doc" (in module)
failed: No such file or directory
2004/11/15 13:25:14  rsync error: some files could not be
transferred (code 23) at main.c(397)
After this error, I tried to copy a complete directory which caused the
first mentioned problem. It appears that the pathname somehow gets
misinterpreted and split into two separates. Which in this last case,
causes not existing path-/filenames. If this same pathseparation occurs
in the first case, it might explain its behaviour to start working on
"module/" or whatever.
It appears that rsync misinterprets certain pathnames, splits them up to
start working on them separately.
Doing so, in my case, might have caused an additional error while
receiving files. Either because of the "path separation" itself or
because the working on millions est. of files or it might be a
completely other bug. (transferring "xxxxxxxx/d/Users Shared
Folders/Gebruikers/USERS VdeM total oude server/Archief
ex-medewerkers/Jeffrey Colley/" did not cause any problems but that
might be because the pathnames are shorter because of relativity)
Although I'm a developer myself, my experience with C(++) is VERY
limited so haven't tried to debug rsync myself as I haven't got a clue
where to start.
Any suggestions, fixes or support in anyway will be greatly appreciated.
Eric van Blokland
I mentioned that I had no problems transferring from Windows to Linux,
this I true except for one rare occasion with the system. This is a
The directory /cygdrive/d/Users Shared Folders/ gets transferred
(Windows to Linux). This path contains the directory "Gebruikers VdeM".
This directory will be created on the server, however, additionally the
directory "Gebruikers" gets created (which doesn't exist on the client)
and the contents of "Gebruikers VdeM" will be transferred there instead.
I mention this (bug?) here as well, because it might be related.
-------------- next part --------------
HTML attachment scrubbed and removed
More information about the rsync