similar to: syncronizing file content into device content

How hard would it be to have rsync do the file recursion scan on both the source tree and the destination tree at the same time in parallel? Would that require a protocol change, or could just a program change be enough? I have some very large directories I'd like to syncronize. Total time to scan through these millions of files is a substantial portion of an hour or even exceeds it. It

The cause is, of course, that the tree being syncronized ie getting larger, so of course rsync is slowing down. But in the case of my particular file tree, there is a way it could be speeded up, but this would obviously also need a change in the rsync protocol to accomplish it. Any tree that has major unchanged subbranches would benefit from this. The file tree I'm syncronizing in this case

I think someone posted this before, but I can't find it in the archives. I am using rsync to pull down source files to be compiled. The delete options are used to clear out any old files left over from previous. Normally this works. I've run into one case where it persistently fails. Within the directory created during compiling is a symlink to another directory, also created during

After doing a fresh extraction of the source for 2.6.0, I execute ./configure and it enters a loop with no output before or during. I let run 20 minutes just to see if it would ever do anything and it did nothing else. Host system has: Linux: 2.4.23 Slakcware: 9.0 bash: 2.05b.0 gcc: 3.2.2 glibc: 2.3.1 I have a big (huge) strace of it here:

Are there any clients and/or servers for Windows (clients only for Win98/ME) which can use the rsync protocol, or especially rsync over SSL (e.g. like stunnel, not ssh), which would allow setting up some well controlled and secure bulk file exchanging between Windows an Unix? SMB is not going to be an option and a VPN may not be an option, either (there are technical reasons for that but they are

I'm trying to set up a machine which will be running multiple instances of NSD to serve different sets of zones from different interfaces. What I'm running into is that I can't specify different PID files to refer to on the command line. Are there any shortcuts or do I need to go write a patch? Any other implications of multiple instances? --

I was under the impression that --include and --exclude worked by matching patterns in the order given, and whichever matched first, whether that was an include or exclude determined the action for that file. I have a big directory from which I am attempting to transfer selected files. I want all files where the first level directory is anything, the second level directory is "2005"

I get this error: ============================================================================= KLIBCCC usr/kinit/resume.o usr/kinit/resume.c:15:66: linux/config.h: No such file or directory make[2]: *** [usr/kinit/resume.o] Error 1 make[1]: *** [all] Error 2 make: *** [klibc] Error 2 ============================================================================= There is no linux/config.h in

I have the sshd daemon located at /sbin/ssh_22 in this scenario (because I have more than one daemon with separate executable images). After upgrading from 3.6.1p2 to 3.7p1, with the /sbin/ssh_22 copy replaced by mv (not by writing over the existing image), I do SIGHUP and get this message logged: Sep 16 15:07:36 vega sshd_22[22552]: Received SIGHUP; restarting. Sep 16 15:07:36 vega

Now that I got klibc to build, the next step is to leanr what it takes to compile ... and most importantly, link ... a program with klibc. Past experience with the GNU toolchain tells me GCC will be a bit of a trouble maker in this, probably trying to make inappropriate library references that would work fine with glibc. I do not currently have any intent to make shared/dynamically linked

It guess I still haven't figured out the entire sematics of the --include and --exclude options. From reading the man page, it seems to say that what happens is that each file being checked is tested against each pattern in order, and when one matches the tests end, and whether it is --include or --exclude determines if that file is included or excluded. So I have on my server a big file

Under certain circumstances (repeatable with a workaround) the client in openssh-2.1.1p3 and p4 closes file descriptors and then calls select() with the stderr one in the write fd_set. The circumstances which cause this appears to be that the closing of stdin/stdout/stderr occurs before the last of the stderr data is written to stderr. This occurs when a tty is not allocated, but the error

This problem has persisted for as long as I've used rsync. When the --delete option is used, not all files are deleted from the target, even though said files are not present in the source. The particular cases that cause this are when the target has a directory with files, and the source is something else, at least a symlink (this is the case I have seen). I'm taking a guess to say that

A while back, I asked if there had been any consideration in making rsync support direct ssl (as opposed to just ssh). I've been looking around for a secure way (e.g. encrypted, so passwords are never in the clear, and even content is obscured from sniffers) to allow a set of limited-trust users (limited-trust being defined as mostly customers, whom you trust with their own data, but not with

My understanding of the man page description of --exclude vs. --include is that the list of these is kept in order, and file names are searched against these parameters in that order for the first that matches and that one makes the decision. It doesn't seem to be working exactly as expected. But there is a factor involved that's making it unclear, which is whether or not *'s should

Last year I put together a script that did a combined kernel header export from a pristine kernel tarball, then a build of klibc from a pristine klibc tarball. One of the intentions for this was to be independent of the host kernel and its headers, so I could build klibc for other targets of the same architecture. I even did this for a wide range of klibc and kernel version combinations to see

If I understand privsep correctly, and I'm not sure I do as there are some ambiguities in the illustration of what processes are doing what, there is a way to avoid doing fd passing. What I see is that fd passing is done to send the PTY to the user privileged process after the monitor process was requested to set one up. Why not go ahead and have the monitor set one up before it forks the

When using the -z and -B65536 options together, sometimes there is file corruption. Client and server are both compiled against zlib 1.1.4, so the gzip corruption shouldn't be there, right? With -z and -B32768 there is an error, but it is detected in a different way. With -B65536 and without -z all seems to be going OK. With -B16384 and with -z all seems to be going OK. I'm guessing

I would like to specify an entry in /etc/rsyncd.conf such that it operates on a --one-file-system basis always. The path will point to a filesystem mount point, but there is another filesystem that is mounted in a subdirectory. I want to back up only those files in the pointed to filesystem, and not the one mounted within (in that run, anyway). I do not see such an option in man rsyncd.conf. Is

[garbage in Chinese snipped] Is there any way to set up a post-confirmation system for non-subscribers so that their posts do not get distributed unless they confirm first? -- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/ |