similar to: "extraneous" in commit 3bd9f51917ed5718275c6132006be155239a0550

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.

rsync --delete option tells rsync to delete extraneous files from the receiving side (ones that aren't on the sending side).But if a user accidentally deletes a file, there is no way to restore it from the server.If --delete option is not used, and the local hard disk is destroyed, restored data will include old deleted files. Is there a way for rsync server to retain backup of deleted source

When --checksum is used they're calculated in both ends to see if the file should be transfered. This is of course not necessary if the file doesn't exist in the destination. However, the checksum is still calculated by the sender, which is often a very large overhead. Would it be possible to avoid it?

patch is for rsync cvs sources after appling acls.diff and xattrs.diff patches. Please comment or include it upstream. PS: please cc me, I'm not on list ---------------------------------------------------- Producenci "Opowie?ci z Narnii" przedstawiaj?: Wielka przygoda w ?wiecie, w kt?rym wszystko jest mo?liwe! MOST DO TERABITHII - w kinach od 9 marca!

https://bugzilla.samba.org/show_bug.cgi?id=2802 Summary: rsync uses extraneous libresolv.dylib Product: rsync Version: 2.6.5 Platform: PPC OS/Version: Mac OS X Status: NEW Severity: trivial Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: psfales@lucent.com

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

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.

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:

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

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

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

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

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

I can reproduce this. It has to do with whether the value rounds down to 9 or up to 10, and thus needs another space, I think. I agree that it shouldn't happen, but at least you can get rid of the space by using trim = TRUE. # rounds to 9 vs 10 format(9.95, digits = 2) format(9.96, digits = 2) format(9.95, digits = 2, nsmall = 2) format(9.96, digits = 2, nsmall = 2) format(9.95, digits =

Looking through the build files I'm wondering if we can't do some clean-up and remove extraneous kruft before we release. Like the config.dbs and the README.build that talks about the config.dbs. From looking through the build setup I don't see either file actually critically needed and looks like Ralph may have come to a similar conclusion by the comments added to the README.build

Dear R Core Team, First of all, thank you for your amazing work on developing and maintaining this wonderful language. I just stumbled upon the following behavior in R version 3.6.0: format(9.91, digits = 2, nsmall = 2) format(9.99, digits = 2, nsmall = 2) yield "9.91" and " 9.99" with an extraneous whitespace. My expected output for the second command is

I ran into a puzzling minor behaviour I would like to understand. Reading in a csv file, I find an extraneous "." after a column header, "in" [short for "inches"] thus, "in.". Is this due to "in" being reserved? I initially blamed this on RStudio or to processing the data through LibreCalc. However, the same result occurs in a console R session.

Hello all, I thought --recursive and --delete-before might be an option and I can quit rsync when it begins the updates, but the incremental recursive scanning is disabled and this will certainly crash rsync as it was before moving to v3.x (too many files). I have no experience with --write-batch but I wonder if it's safe/sane to edit the resulting batch output file, or by doing a