similar to: daemon and absolute sym-links

I'm 99% sure there is a bug in rsync when running in daemon mode on a 'remote' server. The bug is that when trying to rsync a sym-link, the daemon 'leg' of the code strips off the leading path separator (for linux, this would be a '/'). I have produced a 'fixed' version of the code and we have been using it for at least 6 months. We've also used the

Hi Folks -- I've recently had the need to add a piece of functionality to rsync that allows one to run 'rsync --daemon' (rsync in "rsync server" mode) over SSH. My main goal was to be able to use some of the features from rsyncd.conf(5) (notably modules) while still using SSH for authentication and network transport. Background: I wanted to have the capability of setting

-----BEGIN PGP SIGNED MESSAGE----- With rsync --server, sometimes when the remote side control-C's a transfer, rsync will immediately start consuming all available RAM. gdb shows that its recursing while trying to report the failed write: #0 0x420503ac in vfprintf () from /lib/i686/libc.so.6 #1 0x42072f74 in vsnprintf () from /lib/i686/libc.so.6 #2 0x08052ca4 in rprintf

This draft patch adds support for transferring extended attributes with a new --xattr option. It ought to work on Linux with XFS or ext2/ext3 filesystems with the SGI/bestbits attribute system. It is partially working, but there seems to be some kind of hang bug while transferring the file list. I suspect it might be provoking a problem in io.c. You need to rerun autoconf, autoheader and

(As I was composing this, the 2.6.1 release notice on the rsync list rolled in. The quoted source, below, hasn't changed, so I'll leave the 'pre-1' references unchanged...) I have a situation where an error message seems to be sent from the daemon to the client, but none is logged in the daemon's log. Daemon is 2.6.1pre-1, with --timeout=3600, light CPU load. Client is

I am using stepAIC for stepwise regression modeling. Is there a way to change the entry and exit alpha levels for the stepwise regression using stepAIC ? Many thanks, Berthold Berthold Stegemann Bakken Research Center Maastricht The Netherlands [[alternative HTML version deleted]]

Here's a resend of an old patch that is intended to avoid an infinite recursion (ending in a stack overflow) of the rwrite() function getting an error that calls rwrite(), ad naseum. I've only seen this happen when one of the sides dies due to a program error -- in that case, the connection is closed, and when we try to send an error to the other side and it generates an error, the error

My zfs filesystem hangs when transferring large filesystems (>500GB) with a couple dozen snapshots between servers using zfs send/receive with netcat. The transfer hangs about halfway through and is unkillable, freezing all IO to the filesystem, requiring a hard reboot. I have attempted this three times and failed every time. On the destination server I use: nc -l -p 8023 | zfs receive -vd sas

Unless you suppress all output with the -q option, rsync will always print an initial "building/receiving file list ... done" line. In my opinion, this is a bit superfluous. When I want to see a progress indication, I can use the --progress option. Another issue is the 3-line transfer speed and speedup factor report at the end. So every rsync invocation produces at least four lines of

Hiya. While merging the 2.6.0 changes into our modified version of rsync, I noticed the following bit of code in 2.6.0's options.c: extern int sanitize_paths; if (sanitize_paths) sanitize_path(strdup(files_from), NULL); filesfrom_fd = open(files_from, O_RDONLY|O_BINARY); Since sanitize_path modifies its first argument in place, the path that open()

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

Hello everyone! I didn't find anything in the archives that seemed similar (same error, different offending lines of code). I'm having an issue with rsync on a couple of my servers. A couple of others run just fine but 2 of them give me the same message (see below) when I try to do backups from one server to these linux boxes. All of the linux boxes are the same and have the save

When using the rsync server without chroot, the --link-dest and --compare-dest options are almost useless. This is because sanitize_paths is called on the link-dest directory, stripping out leading dots and slashes. Thus, the only possiblitiy for a link-dest directory is under the target directory, which is generally not useful. There doesn't seem to be an easy fix. sanitize_paths is

Recently various needs for multiple version handling were discussed and I put forward a plan of mine. Subsequently the proposal for a --compare-file=<FILE> switch had support, so I have implemented this. I have also implemented an experimental --compare-auto which decides which file to match against using a rule. Instructions for patch: 1. Install rsync-2.5.6 source 2. "patch -p1

Hi! I am doing backups from a number of machines to an rsync server. For some time I was trying to come up with a solution, which would prevent users from peeking at each other's files, which are backed up. Finally, I've hacked rsync, introducing a new option "write only" for rsyncd.conf. When set to true, this option forbids the transfers from server to the client, thus solving

Hi All, I am trying to see the rsync source code. I could see that there are main three processes: I realize that Server or Client becomes Sender or Receiver based on arguments provided. 1. Daemon start_daemon : clientserver.c 2. Server if(sender) { call recv_filter_list : exclude.c call send_file_list : flist.c call send_files :

Since the heap statistics were added, I have viewed thousands of rsync reports (with --verbose and --stats), and not once have I had a need for them. So for me, they're just noise. Here is a 3-part patch to v2.5.6 that treats --stats in a similar fashion to --verbose in that additional --stats will get you more statistics. For this initial case, there's only one additional level of

Gunnar, Check (ll -d dirname) to make sure that there is at least x permission for everyone in each directory down the /var/adm/slh/samba/locks path; also, does the STATUS..LCK file exist in the named directory, and if so what are the permissions on it? Hope this helps, Don -----Original Message----- From: Bakken, Gunnar [mailto:bakkengj@mail.slh.wisc.edu] Sent: Tuesday, January 16, 2001 6:08 PM

In an experimental setup we obtain z-data samples at equidistant grid points. The surf.gls (Kriging) algorithm produces an error under this circumstance when performing the Choleski decomposition. A workaround is to dither the grid coordinates using (x <- rnorm(length(x)) ; y<- rnowm(length(y))). Question: Is this an expected behaviour of the surf.gls function ? Regards, Berthold

This is a patch to control unix permissions when uploading to a rsyncd-server by setting rsyncd.conf options. cu, Stefan -- Stefan Nehlsen | ParlaNet Administration | sn@parlanet.de | +49 431 988-1260 -------------- next part -------------- diff -ur rsync-2.5.5/loadparm.c rsync-2.5.5-umask/loadparm.c --- rsync-2.5.5/loadparm.c Mon Mar 25 05:04:23 2002 +++ rsync-2.5.5-umask/loadparm.c Sun Mar 2