similar to: weird access function in rsync code.

rsync 2.5.0 still has a bug where it hangs under some circumstances. The hang is beyond my abilities to track down. I'll keep trying, though, but here are details in case they're of use to anyone else: - Code configured & built on Solaris 2.5.1. - Same binary run on Solaris 2.5.1 (client) and 2.8 (server). - Using rsh transport, but also fails with ssh - Does not fail with

https://bugzilla.samba.org/show_bug.cgi?id=5701 Summary: deadlock on local rsyncing, bisected to commit f303b749f2843433c9acd8218a4b9096d0d1bb8d Product: rsync Version: 3.1.0 Platform: All OS/Version: Linux Status: NEW Severity: major Priority: P3 Component: core AssignedTo:

Hi, I am running mentioned rsync version in daemon mode on a x86 machine which is a Gentoo Linux running kernel 2.4.26 and glibc 2.3.3_pre20040207. During the sync from another machine, the rsync daemon hangs; client receives no data and server waits on select() call. when this happens, rsync server process can only be killed by SIGKILL; no timeout occurs on server side. ssh is not being used for

The attached patch adds some whitespace to the recv_files() function declaration, and renames variable 'f' to 'f_out' in generate_files(). -------------- next part -------------- Index: generator.c =================================================================== RCS file: /cvsroot/rsync/generator.c,v retrieving revision 1.93 diff -b -c -r1.93 generator.c *** generator.c 30 Jun

This mode is useful when a process is monitoring the log for post-processing of transferred files. With --log-after in local mode, both sender and receiver log to the same log file, so it require --log-file with absolute path. We add %o to the default log format, so it will be easy to tell the logs of the sender from the logs of the receiver: 2023/02/14 14:40:25 [559755] building file list

Hi all. I once tried to rsync around 100 GB (10 million files), but version 2.6.6 needed too much RAM and was too slow. Is one of the snapshots stable enough to try this again? Greetings Sven -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url :

Hi, We're encountering a rather weird, sporadic hang during a large-file transfer. A bit of background on the setup: - Host A rsyncs a MySQL database from Host B. Both sides use rsync 3.1.1 on Debian Jessie. - Host B serves the files using rsync --daemon from an ext4 filesystem residing on a thin LVM snapshot. - Host A uses the following command to rsync the files to a btrfs

This patch adds a switch --fat-filenames which replaces all characters that aren't legal on FAT filesystems with an underscore. This is the first time I touch the rsync code, so I may not be going about it the right way, but it seems to be working. Naturally there's some potential for collisions, but it's probably better than what happens currently (such files are simply not copied).

I tried rsync 2.6.1cvs on my FreeBSD 4.X boxes. It dumps core when preserve_hard_links and backup. And SUPPORT_HARD_LINKS is true. rsync -avH --delete --backup --backup-dir=/some/backup/dir \ srchost::dir/ dir/ The core says... ------------------------------------------------------------------------ Program terminated with signal 11, Segmentation fault. #0 0x80536c0 in keep_backup

I'm backing my Ubuntu server up to an HFS+ case-sensitive volume on our iMac using the below rsync command and it hangs at the end. Compiling rsync 3.0.8 by hand with CFLAGS=-g on both systems shows that all rsync processes are in read_timeout(). $ rsync \ --delete-delay \ -P \ -v \ -A \ -X \ --fake-super \ -aH \ --numeric-ids \ --exclude '/dev' \

https://bugzilla.samba.org/show_bug.cgi?id=11683 Bug ID: 11683 Summary: hang on select when send many files Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter: tom916 at

I've noticed the 3.0.0pre versions sometimes hanging while doing a local copy (through dirvish). This time a had a binary with debugging symbols, so I could do gdb backtraces. This is the result: # ps -fe | grep rsync root 3712 3710 0 02:04 ? 00:00:03 rsync -vrltH --delete -pgo --stats -D --numeric-ids -x --exclude-from=/backup/0/oudeserver/laatste/exclude

https://bugzilla.samba.org/show_bug.cgi?id=8308 Summary: rsync: exclude.c:532: change_local_filter_dir: Assertion `dir_depth < 4096/2+1' failed Product: rsync Version: 3.0.8 Platform: x86 OS/Version: Linux Status: NEW Severity: major Priority: P5 Component: core

Wayne, Please consider the attached patch. This applies to the current CVS, and is independant of patches/local-batch.diff. As a matter of fact, I'm sure it would conflict heavily with local-batch.diff. This version of batch mode has a couple distinguishing features: Write-batch records (almost) the entire sender side of the conversation into one file. ("Almost" because it has

Hiya, I can see it's a regular subject on this list. I, like others wanted to use rsync to synchronise two block devices (as it happens one lvm volume and one nbd device served by qemu-img on a remote host from a qcow2 disk image so that I can keep the old versions) As I couldn't find any report of it being done successfully, I'm just sharing my findings as it might benefit others.

Here's a patch that makes rsync try to find an existing file in a group of hard-linked files so that it doesn't create the first one in the group from scratch if a later file could be used instead. Details: I decided to avoid having the code do an extra scan down the list when we encounter the lead file in the list. This is because it would be bad to have to do the same scan in the

Hey guys, I've been working with rsync for the last couple weeks and I really need some help here. Linux to Linux transfers are working beautifully, but for the life of me I can't get transfers from win2k to work. I have the exact problem that was reported by Mark de Jong on Tue, 16 Jul 2002. I'm using the lastest version of cygwin, with rsync 2.5.5 and ssh 3.5p1 for my tests. The

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

Hi: I'm in the middle of recoverying from a tactical error copying around an Mac OS X 10.10.5 Time Machine backup (turns out Apple's instructions aren't great...), and I had rsync running for the past 6 hours repairing permissions/acls on 1.5 TB of data (not copying the data), and then it just died in the middle with: .L....og.... 2015-03-11-094807/platinum-bar2/usr/local/mysql

While going through an old todo list I found that these patches had fallen by the way-side. About a year ago I initiated a discussion[1] with the Linux kernel folks regarding the lack of any useable fadvise support on the kernel side. As a result, I was observing extremely poor performance on my server after backup as executable pages were being swapped out in favor of data waiting to be flushed