similar to: rsync-3.0.3 crashes with protection exception

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

As you all know, rsync doesn't have any special handling for Mac OS X HFS+ resource forks. Kevin Boyd made RsyncX and rsync_hfs, to address this gap, but they only work when the destination filesystem is also HFS+. I haven't been able to find any references to an rsync that is capable of syncing from HFS+ to UFS (etc). The only solutions I've seen involve lots of preprocessing

We use rsync in a Linux installation script. First, the root filesystem of another machine on the network is cloned with "rsync -axzH", and then a few files are updated to give the clone its own identity. This works fine, but last week, the Postfix mailer daemon on a new machine refused to start because some lock files had a link count of 2. It turned out that rsync had created two

https://bugzilla.samba.org/show_bug.cgi?id=8053 Summary: Older C compilers don't allow in-line declarations flist.c:1653 Product: rsync Version: 3.0.8 Platform: All OS/Version: FreeBSD Status: NEW Severity: minor Priority: P5 Component: core AssignedTo: wayned at samba.org

https://bugzilla.samba.org/show_bug.cgi?id=1448 Summary: core dump in send_file_name Product: rsync Version: 2.6.2 Platform: x86 OS/Version: NetBSD Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: eravin@panix.com QAContact:

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

> I like the idea of your rsync-exclude.patch and have thought > about hacking it in myself. However as you already have done the work > may I make a small suggestion...... can the name of the exclude file > (your .rsync) be specified in the flags.... e.g. > > rsync --rsync-exclude=.snapshot -axvH /here /there > > In this way different invocations (e.g. system and

https://bugzilla.samba.org/show_bug.cgi?id=8475 Summary: memory leak around free_xattr() and rsync_xal_free(), with -aX, 200 bytes per file and per directory Product: rsync Version: 3.0.9 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core

I have been trying for quite a while now to understand why is the flist.c:f_name() function implemented using static buffers. Anyone care to comment? The immediate problem is that any call to f_name overrides the previous content (well, obvious). This, combined with the fact that several function calls are made with the result of f_name(file) results in problems handling hardlinks - and

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 have two DOS filesystems mounted on Linux as "vfat" which I want to rsync. (They are on flash cards, so that they are also small). rsync gets tricked because the filesystem treats names differing in only case as the same. Thus, when it tries to sync "FOO123" with "foO123", it copies over the "new" file, and then renames it over the old one (which it

hello, i use rsync as a major backend for our automatic debian GNU/linux workstation synchronisation project at the Free University of Berlin / Computer Science. my concept is, that rsync gets the class, group and machine-specific root-trees as argument, and it's up to him to find and automaticaly remove duplicated files on the basis of the priority (which is actually the argument list).

I need to select 1 record from each client. This record has the charge with the most severe charge type (lowest charge_type_id). How do I go about this? I have been using a find_by_sql query out of the client.rb that looks like: SELECT c.f_name AS f_name, c.l_name AS l_name, c.gender AS gender, c.race AS race, c.dob AS dob, c.address AS address, c.city AS city, c.state AS

This one has been biting me recently, and it seems to be completely deterministic: it utterly fails on most directories, but when it fails on one, it does so reproducibly. Also, I'm doing a simple copy from one directory on my machine to another - there is no remote server or network to fail. The drive is only 24% full. Here's my take on it: 1) The error is printed as occurring in

Wayne, I've been ruminating a bit on the qsorted flist and duplicate removal and have an idea. What if we removed end_file_entry() from send_file_name() and instead had a for(i=0; i < flist->count; ++i) send_file_entry(flist->files[i], f, ??) in send_file_list(). As near as i can tell this would be unnoticeable to the protocol. Once done the sort of the file list could be

I'm getting a SEGV on a FreeBSD 4.8-STABLE box. The client is Solaris 9/SPARC. Both boxes run 2.6.2. The command I'm running is: $ rsync -arHRv --numeric-ids --delete --exclude=/opt/dist/cdrom \ [paths] [server]:[path] If I whittle down what appears in [paths], then it works. $ gdb rsync rsync.core gdb> bt #0 0x280faf0d in strncmp () from /usr/lib/libc.so.4 #1 0x7 in ?? () #2

https://bugzilla.samba.org/show_bug.cgi?id=1959 Summary: writefd_unbuffered failed to write 4092 bytes phase send_file_entry broken pipe Product: rsync Version: 2.6.2 Platform: x86 OS/Version: Linux Status: NEW Severity: major Priority: P3 Component: core AssignedTo:

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

As those of you who watch CVS will be aware Wayne has been making progress in reducing memory requirements of rsync. Much of what he has done has been the product of discussions between he and myself that started a month ago with John Van Essen. Most recently Wayne has changed how the file_struct and its associated data are allocated, eliminating the string areas. Most of these changes have been

https://bugzilla.samba.org/show_bug.cgi?id=8019 Summary: Various improvements to the fileflags patch Product: rsync Version: 3.0.8 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: mike at bombich.com