search for: blorf

Hello Regarding ownership on the destination: rsync's man page indicates that when synchronizing files to a remote host, -o implies the --numeric-ids option, which makes perfect sense aince the named users/groups may not exist on the destination host. The problem I have is that the files created on the destination still appear to be owned by the local user (server1) on the rsync

I've got a patch that changes f_name_to() to return an unsigned int (like snprintf() and strlcpy() do) and adds checking to ensure that we didn't overflow the name before we try to use it: http://www.blorf.net/name-overflow.patch If anyone would care to check out the following patch before I commit it, please do. ..wayne..

...- You can get the /some/list file from the remote end of the connection by specifying either "remote:/some/list" or just ":/some/list" (note that "remote" must be the same hostname as one end of the transfer). Where To Get It: ================ http://www.blorf.net/rsync-files-from.patch Still To-Do: ============ - The patch needs testing to ensure that it is working well (I've tested all 4 combinations of send direction and list-file source location, but more is needed). - I need to ensure that the user's input data doesn't contain...

...than calling io_flush() in a loop. In my exuberance for having finally solved the redo-hang problem in a much better way than my previous suggested fixes for it, I went ahead and checked in my changes. However, feedback is still gratefully accepted. The changes can be found here: http://www.blorf.net/redo.patch ..wayne..

As threatened a while back, there are some exclude/include bugs that I'd like to see fixed in rsync. Here is the patch: http://www.blorf.net/rsync-exclude.patch This fixes the following bugs: - A non-anchored, slash-including pattern with a wildcard needs to be matched at the end of the path (e.g. "CVS/R* should match throughout the tree, not just at /CVS/R*). - A leading "**/" should match at the root of t...

I've released rsync 2.6.0pre2. This should be the final pre-release before 2.6.0 goes final (which is scheduled to happen on January 1st). If you'd like to assist in making the final release smoother, please try this out and let me know if you encounter any problems: http://samba.org/ftp/rsync/preview/rsync-2.6.0pre2.tar.gz http://samba.org/ftp/rsync/preview/rsync-2.6.0pre2.tar.gz.sig

I've released rsync 2.6.0pre2. This should be the final pre-release before 2.6.0 goes final (which is scheduled to happen on January 1st). If you'd like to assist in making the final release smoother, please try this out and let me know if you encounter any problems: http://samba.org/ftp/rsync/preview/rsync-2.6.0pre2.tar.gz http://samba.org/ftp/rsync/preview/rsync-2.6.0pre2.tar.gz.sig

I know this has been discussed repeatedly, so might even say beaten to death, but it is a feature which I need to use. I notice Wayne had a patch to do this listed in the list archives, but I don't know what version of rsync he was patching against. What is the general opinion on using this patch for reliable rsync'ing of extremely small volumes of data of high cost, high latency comms

I've noticed that even if rsync has a non-zero exit code on the client that the server still reports an exit status of 0. For example, I've received an error 23 with the following output on the client-side "rsync error: some files could not be transferred (code 23) at main.c(954) [sender=2.6.9cvs]" while the server-side rsync_raw_status and rsync_exit_status were still both

Hi, My name is Vu Huynh. I'm currently work for Atmel Corporation. We're using Rsync v2.5.7 to rsync design kits between our remote sites. It works fine for all small kit directories. However, there is 1 BIG kit directory (But there is no file has the size of bigger than 100MB) that always gets "rsync: connection unexpectedly closed" Error. The Full Error Message

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

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

Back on April 4th I sent a patch that makes UseLogin work on Solaris. This change also made UseLogin work with Unicos (both of which require a valid utmpx entry before /usr/bin/login will run). I have not heard back from any of the ssh developers about this issue, and the current snapshot doesn't appear to deal with this problem at all. So, is there some issue here we still need to deal

It would be nice if the CVS source had a .cvsignore file in the main dir with the following items: ssh scp sshd ssh-add ssh-keygen ssh-keyscan ssh-agent sftp-server sftp configure config.h.in config.h config.status Makefile ssh_prng_cmds *.out Plus a .cvsignore file in openbsd-compat that ignored "Makefile". ..wayne..

I'm seeing a linking problem with scp on Solaris 2.6 that I'm not seeing on Linux (Mandrake 8). It boils down to Solaris not having mkdtemp(), and the mkdtemp() compatibility function referencing arc4random(), which calls seed_rng(). Since that function is back in libssh.a, we get a function-not-found link error. I added -lssh after -lopenbsd_compat on scp's build rule (so it is

Using UseLogin on a system that has to twiddle utmpx before calling login currently also twiddles wtmpx, and this causes problems on Solaris in the "last" log. Changing the source to avoid modifying wtmpx when also modifying utmpx fixes things up nicely: Index: loginrec.c --- loginrec.c 2001/05/08 20:33:06 1.33 +++ loginrec.c 2001/06/06 17:14:25 @@ -456,9 +456,10 @@ # endif # ifdef

One other thing I noticed in the record_utmp_only() function is that it wasn't setting the timestamp in the logininfo structure. The following patch takes care of this: --- old/loginrec.c Wed Jun 6 11:12:14 2001 +++ loginrec.c Wed Jun 6 11:13:42 2001 @@ -448,6 +448,8 @@ login_utmp_only(struct logininfo *li) { li->type = LTYPE_LOGIN; + /* set the timestamp */ +

If you've applied my previous scp patch with the tempfile options and the erase option, here's a diff that tweaks it a bit more. Previously I had decided to use getcwd() in a certain local-to-local special case (that needs to use scp rather than regular cp). This was because spawing scp via ssh resets the current directory. This patch choose to forego that in favor of a simpler

Since multiple people have applied my UseLogin patch and failed to get it to work because configure/config.h.in were not automatically rebuilt, I decided it was time to add some rules to the Makefiles to update these things. The appended patch will cause a "make" to rebuild configure, config.h.in, config.h, and both Makefiles if the appropriate source file(s) change. It will also run

I'm using openssh 2.5.2p2 on Solaris-x86 2.6. I ran into a couple problems when I set UseLogin to "yes": The big one seems to have been reported before: login refuses to run without a utmpx entry. This problem appears to have been caused by the changes in revision 1.24 of session.c. Before this revision, the record_login() function was always called, no matter how UseLogin was