similar to: inefficient: --checksum calculation shouldn't be done for new files

I've just got the log lines below. The first line shows the format spec that prints each column: %'b %'l %f 0 18,760 f1 0 11,193 f2 32,768 2,186 f3 3,128,368 3,453,856 f4 13,680 11,786 f5 32,768 6,288 f6 0 6,498 f7 0 6,346 f8 0 6,570 f9

In the latest 3.1 I get this in our backup: filename overflows max-path len by 1: <path> filename overflows max-path len by 1: <path> filename overflows max-path len by 9: <path> filename overflows max-path len by 7: <path> filename overflows max-path len by 4: <path> filename overflows max-path len by 5: <path> filename overflows max-path len by 6:

Got this in the log: rsync error: errors with program diagnostics (code 13) at log.c(340) [generator= 3.1.0dev] What could it be? I suspect it's triggered by a timeout or disconnect from the server side but I had never seen it.

https://bugzilla.samba.org/show_bug.cgi?id=10552 Summary: Sender checksum calculation significantly slower with compression enabled Product: rsync Version: 3.1.1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at

Got this with rsync --list-only --files-from=list directory dummy > output 2> errors to get a local file list: ... rsync: link_stat "file-name" failed: No such file or directory (2) rsync: link_stat "file-name" failed: No such file or directory (2) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1141) [sender=3.1.0dev] rsync:

I'm having two problems. The first is that when running with --files-from and -ii unmodified files are not put in the log. --out-format=%-14b %C %-14l %i %B %M %f All that appears in the log is Number of files: 0 Number of created files: 0 Number of regular files transferred: 0 Total file size: 0 bytes Total transferred file size: 0 bytes Literal data: 0 bytes Matched data: 0 bytes File list

When --partial-dir is used rsync creates new or updated files inside a temporary dir. For example the new version of some/path/file is created in some/path/<partial-dir-name>/file and later moved. What happens if a new directory is created? If some/path/newdir/newfile is to be copied, is it done in some/path/<partial-dir-name>/newdir/<partial-dir-name>/newfile? Or is newdir

Got this strange error: receiving incremental file list rsync: opendir "/.~tmp~" (in <sender-module>) failed: Permission denied (13) IO error encountered -- skipping file deletion rsync: opendir "/path/.~tmp~" (in <sender-module>) failed: Permission denied (13) invalid multi-message 22:4 [sender/inc] *************************************** rsync: connection

It seems the latest timeout changes in 3.1 work well. I was having repeated timeout aborts in a sync of large files through a very slow connection, which made each file transfer take very long. The latest version no longer aborts and the sync finished successfully. The destination used version 3.1 and the origin some 2.9; protocol was 29.

3.1, including the latest version, produces bogus ---stats output: % rsync -r --stats . > /tmp/3.1-n % tail -n 17 /tmp/3.1-n Number of files: 3,159 (reg: 2,984, dir: 173, link: 2) Number of created files: 0 Number of deleted files: 0 Number of regular files transferred: 0 Total file size: -6,417,895,484,864,819,269 bytes ************************************************* Total transferred file

Hi all, I am using rsync v.3.0.7 (protocol v30) on ubuntu 10.04. My rsync line looks like this, cd /home/shantanu/ rsync -av --files-from=bin/include-to-rsync.dat /home/shantanu/ \ /media/transcend/backup_laptop/shantanu/ include-to-rsync had directories in this format, bank/ dwhelper/ clients/ When I ran the script I noticed that a files in bank/10-11 were not getting synced. Upon

https://bugzilla.samba.org/show_bug.cgi?id=8817 Summary: Custom format for --list-only Product: rsync Version: 3.0.9 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: abacabadabacaba at gmail.com

The prescription for Boot Info Table says that checksumming begins at byte 64 of isolinux.bin. When prepcore writes isolinux.bin it begins copying bytes from the input file at the offset given by variable "start". But it begins checksumming at offset 64 of the input file. The problem exists since introduction of prepcore by release 4.00. ISO 9660 programs usually fix it when they write

Hi, I've a directory of large log files (> 100M) that I want to rsync to another server in short intervals (say every minute). With the --append option I can avoid resending whole files at every sync. But rsync still calculates the checksum over the complete files every time, which claims a significant share of CPU and IO resources. Since the log files are always written in append-only

Hi, With an rsync-2.6.4-3 client talking to an rsync-2.6.8-1.el4.rf server at least, the --ignore-times option seems not to be honoured? I.E. if I edit a file so that the mtime and size are the same, the file with the new data will not be transfered to the server. In case it's important, the full command I run is: rsync -viIaz --delete -e ssh . www.pixelbeat.org:'~/public_html'

Hello Rsync devs, We're investigating ways to provide large scale software updates for multi-gigabyte games, and have recently begun to explore whether rsync may fit the bill. In particular, the checksum-updating patch looks like it might be able to solve our biggest concerns about CPU load on the update server, since the actual content being served will change quite rarely. Would an

Hi, Where can I get good pointers on the rolling checksum algorithm used in rsync? I need an 8-bit or 12-bit rolling checksum too. Any place where "rolling" checksum algorithms are discussed? Seun Osewa ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

On Fri, 17 Apr 2015 21:27:56 -0400, Kevin Korb wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Any time rsync wants to do something to a file you don't think it should > be see what --itemize-changes says about it. In fact, -v is almost > entirely useless without --itemize-changes. In fact, if I was in charge > I would make -v include --itemize-changes.

hi here some questions about the md5 checksum: - what happens when the md5 checksum of the decoded audio is different of the internally stored checksum due to file corruption ? Will playing/decoding still be possible (with some error frames) or will playing /decoding be not possible at all (so all audio data is lost)? - what happens when the metadata blocks get corrupt? will the audio part

Hi, as scanning large repositories for each client connection causes unnecessary CPU/IO load, I want to know if is it possible to generate checksum digest files on the server, meanwhile? Best regards, Renne