similar to: �����M�~�W���q������-- �����q

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

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

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

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

I'm finding even less on rsync and SSL. I would have imagined someone would have done something with this already, but apparently not. So I guess I need to ask and see for sure: has anyone worked on issues of using rsync via SSL, such as with stunnel? I want to have encrypted access, either anonymous or authenticated, but without granting any SSH access to anyone (e.g. the rsync

Is there a configure option to build OpenSSH mostly statically? I want to have openssl libraries statically linked. I'd prefer libc (and related) not be, and libz could go either way. -- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/ |

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 presume the option --copy-unsafe-links really means to copy the file contents a symlink points to, even outside the tree being copyed, rather than make a symlink on the destination. What I find is that if a symlink on the source is dangling, that is, it points to nothing that exists, that symlink is not created at the destination. What I want is for all symlinks to be reproduced as symlinks

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

Since nothing is to be written into /var/empty (or whatever the path de jour is) I would assume it would be safe to make it be a read-only filesystem. -- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/ |

Is there a way to specify to rsync that metadata should NOT be updated unless the object was created, or the contents of a file was modified. Specifically, what I want to do is use rsync to "install" a file tree of a few changes (a package being replicated to multiple machines after it has been compiled). The problem is that the file tree created to hold the files from the install does

Server host config: Slackware 8.0 (custom boot scripts) glibc-2.2.3 gcc-2.95.3 Linux-2.4.18 Client host config: (same as server) Symptom: session disconnects with no message to client: ============================================================================= phil at antares:/home/phil 153> ssh -V OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f phil at antares:/home/phil 154>

What risk exists in changing the check for the matching version of openssl so that the final letter part of the version (e.g. 0.9.6c vs. 0.9.6d) is ignored? Are there any security vulnerabilities in such a thing? What if ssh(d) is linked against an older _letter_ version such as 0.9.6c and now finds the library is 0.9.6d? Is there a security risk in that? Surely a major API change would not

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? --

Any ideas of the best way around this problem? Should I just hack the source code, or is there a magic switch somewhere I'm missing? I'm assuming I can't just dismiss that function as OpenSSH is probably based on the OpenBSD semantics. ============================================================================= gcc -g -O2 -Wall -Wno-uninitialized -I. -I.

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:

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

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 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

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