similar to: rsync 2.6.1pre-2 is now available

As mentioned on the rsync home page, the --files-from=FILE option in rsync version 2.6.0 is a useful option that allows one to "specify a list of files to transfer, and can be much more efficient than a recursive descent using include/exclude statements (if you know in advance what files you want to transfer)". However, --files-from does not help one implement the --rsync-exclude=FILE

As I alluded to in an earlier email on the subject of excludes, I had the idea of allowing a merge idiom (think "#include" in C) inside rsync's current exclude/include system. The idea is simple -- use the prefix ". " (dot space) in front of a filename, and that file will be incorporated into the contents of the current exclude/include rule(s). As a further feature, if the

On my server I have a directory at the root, /rails/ which contains other directories with rails projects. In my httpd.conf I have RewriteEngine On RewriteLog "logs/rewrite.log" RewriteLogLevel 9 RewriteCond %{REQUEST_URI} !^/rails/([^/]+)/public/ RewriteRule ^/rails/([^/]+)/?(.*)$ /rails/$1/public/$2 [QSA,L] So with a GET /rails/test/ you''d get sent to /rails/test/public/ and

I received the following bug report for the Debian rsync package today. I wouldn't have expected 2.6.4 to refuse to talk to even a 2.6.2 in this way... Perhaps Wayne could comment? Paul Slootman On Tue 26 Apr 2005, Alexey Feldgendler wrote: > > Rsync fails to push filters to the the remote host if the remote rsync > is older than the Debian's. I've tried to connect to a

On behalf of the development team of R (www.R-project.org), I would like to report the following problem with recent versions of rsync. First, some background info. The R Development Core Team uses CVS for maintainins its source code archive. Additionally, there is a mechanism for "mirroring" some important (so-called recommended) extension packages from a CRAN (Comprehensive R

There are two security advisories for people who run a writable rsync daemon. One affects only those with "use chroot = no" (which is not a very safe combination in general), and one affects a daemon that has daemon-excluded files that are being hidden in a module's hierarchy. Included are simple config-change suggestions that should help you to avoid the security issues. These

There are two security advisories for people who run a writable rsync daemon. One affects only those with "use chroot = no" (which is not a very safe combination in general), and one affects a daemon that has daemon-excluded files that are being hidden in a module's hierarchy. Included are simple config-change suggestions that should help you to avoid the security issues. These

SUMMARY There is a path-sanitizing bug that affects daemon mode in all recent rsync versions (including 2.6.2) but only if chroot is disabled. It does NOT affect the normal send/receive filenames that specify what files should be transferred (this is because these names happen to get sanitized twice, and thus the second call removes any lingering leading slash(es) that the first call left

I have noticed that the contents of per-directory .cvsignore files apply outside their subtrees when using --cvs-exclude in rsync 2.6.0. In the results below, notice how dir1/.cvsignore is applying to a file in dir2. There is no ~/.cvsignore, and the CVSIGNORE variable is unset. % ls -AFR .: dir1/ dir2/ ./dir1: .cvsignore file1 ./dir2: file2.foo % cat dir1/.cvsignore *.foo % /usr/bin/rsync

Here a bug report about "!" not working properly in 2.6.4 and above, paraphrased... > Ok, see attachment. I've tested it right now between two hosts > running rsync 2.6.3-2 and 2.6.6-1. It works in the forward direction, > backwards it gives > > '!' rule has trailing characters: ! > rsync error: syntax or usage error (code 1) at

> 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

On Thu, Jul 19, 2007 at 06:24:10PM -0400, Matt McCutchen wrote: > The remote rsync is running out of memory as it collects the CVS > ignore rules (add_rule). Something could be awry with the CVS ignore > rules, or the machine could just be low on memory. Please run rsync > again with -vvv (three verbose options), which will make the remote > rsync show (among other useful

This is a patch to add an --rsync-exclude option to rsync-2.5.6cvs. File names in .rsync- (or .rsync+) are excluded (or included) from the file lists associated with the current directory and all of its subdirectories. This has advantages over --cvs-exclude for backing up large file systems since the .cvsignore files only apply to the current directory: unless the .cvsignore restrictions apply

https://bugzilla.samba.org/show_bug.cgi?id=1582 Summary: rsync dry run cannot find missing folders, contradicts actual run. Product: rsync Version: 2.6.2 Platform: All OS/Version: IRIX Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org

Hi, I can't figure out how to backup a tree with symlinks. I either get errors like rsync: open(rc2.d/S20inetd) failed!!: No such file or directory (2) or (with --safe-link on the client and "munge symlinks = yes" on the server): ignoring unsafe symlink "/etc/rc2.d/S20inetd" (in backups) -> "/rsyncd-munged/../init.d/inetd" What I am trying to do is

I just received this bug report on Debian's rsync package. I've verified it. The entry from the manpage: -C [...] Finally, any file is ignored if it is in the same directory as a .cvsignore file and matches one of the patterns listed therein. Here the patterns of a .cvsignore file is apparently used to exclude file outside the directory where the .cvsignore file is found. Any

Hi guys, I recently stumbled across what I think is an rsync bug. The problem was I was trying to rsync from one CVS checkout, to another, and was using rsync -Cavz to do the job. In this CVS module, there happens to be two sub-directories with the names of "core" and "tags" respectively, which were ignored, since these names matched the default CVS ignore list. When rsync

(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

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

anyone who can help me understand- one of my developers reimported openssh snapshot from 0722 into cvs. he sent me the following email about an error he believes is in the snapshot i'm not a cvs-knowledgeable person, so i'm not all that clear on this, but should *.in files be in .cvsignore? i tried checking a later snapshot, but 0722 seems to be the latest one. .cvsignore is dated jun