similar to: Checksum of a file

I'm in the midst of coding a patch set for consideration that will bump the protocol version and have a couple of observations. The current minimum backwards-compatible protocol is 15 but we have code that checks for protocol versions as old as 12. If someone else doesn't beat me to it i'm considering cleaning out the pre-15 compatibility code. A backwards compatibility patch could

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

Platform: Compaq OpenVMS Alpha 7.3 Compiler: Compaq C T6.5 The following patch resolves compile problems with the checksum.c module. The type (char) was being used where the usage indicated either (void) or (unsigned char) should be used. The const qualifier was added to impove compiler efficiency. There may be more cases in this module where type (char) is being used instead of what appears

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 produces a destination file full of null bytes. I noticed this with 2.5.7, but checked 2.6.2 as

> Just curious: what about the rsync+ patch? Thanks for the reminder. I've just committed Jos's rsync+ patch onto the "branch_mbp_rsyncplus_merge" branch. If it works OK and nobody screams I will move it across onto the main tree tomorrow or Wednesday. I see the patch doesn't add documentation about the new options to the man page, so we should fix that in the future.

Hi, while implementing the rsync protocol in one of our projects I found that the current CVS version still has a MD4 bug. I'm using the FreeBSD libmd implementation and I still had checksum mismatches with protocol version 27 for files whose size was a multiple of 64 - 4 ( - 4 due to checksum_seed). A patch for todays CVS version is attached. Someone should also review the clean_fname()

The attached patch provides an additional check for the checksumming mode to ensure that a file that is actually written out to disk can be read back and has the same MD4 sum as the file on at the originating location. Regards, Nick. -------------- next part -------------- *** rsync-2.6.6pre1/receiver.c 2005-04-14 02:42:13.000000000 +0100 --- rsync-new/receiver.c 2005-07-26

I'm having a problem with large files being rsync'd twice because of the checksum failing. The rsync appears to complete on the first pass, but then is done a second time (with second try successful). When some debug code was added to receiver.c, I saw that the checksum for the remote file & the temp file do not match on the first try, so (as expected) it repeats the rsync & the

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

Hi All, I'm trying a remote backup for the first time. It is between two laptops, I installed rsync 3.0.7 on both compiled patch -p1 <patches/fileflags.diff patch -p1 <patches/crtimes.diff patch -p1 <patches/crtimes-64bit.diff patch -p1 <patches/crtimes-hfs+.dif f patch -p1 <patches/hfs_compression.diff ./configure make this all works perfectly for local backups, clones

Dear R-devel community, There appears to be an inconsistency in R C API about the exceptions that can be raised from C code. Mapping of R C funs to corresponding R functions is as follows. error -> stop warning -> warning REprintf -> message Rprintf -> cat Rprint/cat is of course not an exception, I listed it just for completeness. The inconsistency I would like to report is

Hi all, i am working on an networking product which has a 32 MB flash memory and a 64MB RAM. i need to sync a file named appl.gz which is of size 3.1MB from a unit with ip 192.168.10.1 to a unit with ip 192.168.10.2. the rsync is called from a C code which does a fork-execve operation. the command line options being passed to rsync is as below: command: rsync --stats -aI --temp-dir=/tmp/

Hi, I used --partial to transfer files from my local computer (rsync 3.1.2, Debian) to a remote computer (rsync 3.1.1 WD MyPassport Storage device) The files get transferred, but after successful transfer, the files are not renamed from .<tmpfile> to <file>. Where to go next? Here is the verbose output after transferring an empty file heiko at blade:~/Pictures$ rsync

I've been using 3.0.0pre8 to move a Debian archive from one filesystem to another. This archive contains a daily snapshot of the Debian ftp site, with common files hardlinked to save space. I noticed that it was using far more space than necessary. Upon investigation it seems that all the source files that have inode numbers greater than 2^31 aren't being hardlinked together at the

https://bugzilla.samba.org/show_bug.cgi?id=2187 ------- Additional Comments From qiucheng@csc.com.cn 2004-12-27 01:15 ------- Created an attachment (id=869) --> (https://bugzilla.samba.org/attachment.cgi?id=869&action=view) error log -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact

Hello, i use rsync from Windows to rsync on Linux via ssh and get IO Errors and connection unexpectedly closed errors on almost every sync run. Can anybody give me some hints on how to track down the problem? thx, Chris 2008/10/11 09:41:04 [13744] rsync to backup// from UNKNOWN (w.x.y.z) 2008/10/11 09:41:04 [13744] receiving file list 2008/10/11 09:42:48 [13744] IO error encountered -- skipping

Thank you Luke for prompt reply. Is it possible then to request a new function to R C API "message" that would equivalent to R "message" function? Similarly as we now have C "warning" and C "error" functions. Best, Jan On Sun, Sep 15, 2019 at 5:25 PM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > > On Sun, 15 Sep 2019, Jan Gorecki wrote:

Hi! I try to use batch mode to send only the difference between two packed CDs by email over a slow line. I create the diff with: rsync -avvv --write-batch=rs CD-ROM-V6.6.32.zip CD-ROM-V6.6.31.zip where alfred:/Auslieferung/CD # l -n -rw-r--r-- 1 0 0 453248121 Sep 2 16:22 CD-ROM-V6.6.31.zip -rw-r--r-- 1 0 0 407416499 Sep 29 13:39 CD-ROM-V6.6.32.zip resulting

Hi everyone! I played around with rsync sources a little and wrote a small patch that computes the checksums from parts of the files only. I'm just writing to ask if the rsync developers would have any interest in the sort of functionality described below. If you do, I'm willing to work with you to produce a cleaned up patch for git. For background: This started as a way to satisfy an

I've been having problems trying to sync two small partitions (128MB) that may be near to full. If rsync gets a write error (such as is caused when you fill up a partition) during a sync without the use of "-T", it will stop with this error: rsync: writefd_unbuffered failed to write 4 bytes: phase "unknown": Broken pipe rsync error: error in rsync protocol data stream