similar to: Error from rsync-2.5.2

I am trying to finalize the use of rsync for updatiung a new nfs server before we take the old one offline. I keep getting the following warning during the rsync process: Warning: unexpected rad size of 0 in map_ptr Any ideas where this comes from and how to make it go away? I am using rsync 2.5.2 on Solaris 8 to pull data from rsync 2.5.2 on Solaris 7. Bob roconnor@vectorpartners.com

Hi, I tried to compile rsync-2.5.2 on Solaris 5.7 Ultra-2 machine, 5.7 on Ultra-2 is running 64 bit, but, when I ran configure, it said no for largefile, I thought 2.5.2 will support large file? Is that true? Thanks, Jennifer

We're using rsync to mirror a web server. The rsync is initiated using ssh from a Red Hat Linux 7.2 box, the files are located on an Alpha running a version of Digital Unix 4. On the Alpha rsync is 2.5.2, The Linux box used to have a 2.4.6-X version, but with the map_ptr problems I built 2.5.2 on that as well. However, version incompatibility was not the problem, as they persist after the

Hi list, Since upgrading rsync to version 2.5.2 on a Solaris 2.5.1 box, I see plenty of Warning: unexpected read size of 0 in map_ptr when doing my nightly backup (rsyncing some directories to an rsyncd on the same LAN). I have never seen this message before, and I only see it on the Solaris machine (I upgraded all my other machines to 2.5.2 as well). I hope this is not a FAQ... I did not find

Available now from samba.org and all mirrors. Please report bugs, compilation problems, etc. If there are no major issues I think I will put this out as 2.5.3 shortly, because it fixes a few serious issues. Thanks to everybody who contributed patches. rsync://samba.org/rsyncftp/preview/rsync-2.5.3pre1.tar.gz\* rsync 2.5.3 (not released yet) SECURITY FIXES: * Make sure that

Greetings, I'd like to propose a new option to rsync, which causes it to read device files as if they were regular files. This includes pipes, character devices and block devices (I'm not sure about sockets). The main motivation is cases where you need to synchronize a large amount of data that is not available as regular files, as in the following scenarios: * Keep a copy of a block

Hi, When using rsync-3.0.2 through 3.0.5, I get this error on a large dataset syncing from machine-a to machine-b: $ /bin/rsync -aHSz /local/. machine-b:/local/. invalid len passed to map_ptr: -1737287498 rsync error: error in file IO (code 11) at fileio.c(188) [sender=3.0.5] This happens no matter which side initiates the connection, so this fails in the same way: $ /bin/rsync -aHSz

[I am responding on the cygwin list to a message on cygwin-announce and cc'ing to the rsync list.] From: "Lapo Luchini" <lapo@lapo.it> > I have uploaded version 2.5.2-1 of the open source utility that > provides fast incremental file transfer. > > ChangeLog as on http://rsync.samba.org : Rsync 2.5.2 has a data-destroying bug as described here:

https://bugzilla.samba.org/show_bug.cgi?id=6293 Summary: rsync crashes when transferring files Product: rsync Version: 3.0.5 Platform: x86 OS/Version: Mac OS X Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: dirk.samba@miriup.de

Hi, We got the following error messages when we ran rsync 2.5.2 from Solaris-5.5.1 to Solaris-5.8. vl121909/jagcdms_ch+_diags/sys/sys_l/ch_sys/rtl/systop.v vl121909/jagcdms_ch+_diags/sys/sys_l/ch_sys/rtl/sysup_esat.v vl121909/jagcdms_ch+_diags/sys/sys_l/ch_sys/rtl/upesat_defines.h wrote 63878001383 bytes read 1529124 bytes 1246928.64 bytes/sec total size is 148182624008 speedup is 2.32 rsync

Hi, I just compiled new release 2.5.6 rsync in solaris5.9 machines, and ran a rsync job,I got the following errors: rsync error: unexplained error (code 255) at main.c(620) Both source and destination servers are running 5.9, can you please tell me should I update anything in main.c file? Thanks, Jennifer

Rsync has begun failing to replicate a kerberos samba mount point. This mount point has worked previously, but recently an attempt to replicate the mount point returns; lseek failed in map_ptr rsync error: error in file IO (code 11) at fileio.c(228) rsync: writefd_unbuffered failed to write 4092 bytes: phase "unknown": Broken pipe rsync error: error in rsync protocol data stream (code

Hi, I think I found a bug in usage of zlib. rsync 2.5.6 with -z fails like bellow. % cp install-disk2.iso /var/tmp/install-disk2.iso install-disk2.iso 100% |*****************************| 316 MB 00:56 % rsync -vIz install-disk2.iso 127.0.0.1:/var/tmp/install-disk2.iso install-disk2.iso deflate on token returned 0 (16384 bytes left) rsync error: error in rsync protocol

When a whole-file checksum is performed, hashing was done in 64 byte blocks, causing overhead and limiting performance. Testing showed the performance improvement to go up quickly going from 64 to 512 bytes, with diminishing returns above, 4096 was where it seemed to plateau for me. Re-used CHUNK_SIZE (32 kB) as it already exists and should be fine to use here anyway. Noticed this because

https://bugzilla.samba.org/show_bug.cgi?id=9894 Summary: Rsync can silently zero out chunks in a file Product: rsync Version: 3.0.9 Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: an.m at outlook.com

Attached is a patch that makes window strides constant when files are walked with a constant block size. In these cases, it completely avoids all memmoves. In my simple local test of rsyncing 57MB of 10 local files, memmoved bytes went from 18MB to zero. I haven't tested this for a big variety of file cases. I think that this will always reduce the memmoves involved with walking a large

https://bugzilla.samba.org/show_bug.cgi?id=1936 Summary: lseek failed in map_ptr Product: rsync Version: 2.6.3 Platform: x86 OS/Version: Windows XP Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: jitbose@yahoo.com QAContact:

Warning for kernel folks: I'm not much of an mm person; let me know if I got anything horribly wrong. Many folks use rsync in their nightly backup jobs. In these applications, speed is of minimal concern and should be sacrificed in order to minimize the effect of rsync on the rest of the machine. When rsync is working on a large directory it can quickly fill the page cache with written data,

We've just been hit rather badly by a very nasty bug that can cause rsync to silently discard files or fill them with zeroes. It happens when e.g. opendir() succeeds but readdir() returns an error; rsync does not check for an error from readdir() and so simply ignores the error (along with any remaining files in the directory). No error is reported to the user, who will then happily

Mark II of the patch set. The first patch (dynsumlen2.patch) increments the protocol version to support per-file dynamic block checksum sizes. It is a prerequisite for varsumlen2.patch. varsumlen2.patch implements per-file dynamic block and checksum sizes. The current block size calculation only applies to files between 7MB and 160MB setting the block size to 1/10,0000 of the file length for a