similar to: patch against manpage

Two patches: one to correct the spelling of permissions (in comments, but such typos disturb me as well), and one to cast inode and dev to unsigned long before comparing, to prevent gcc giving a warning "comparison between signed and unsigned". Paul Slootman -------------- next part -------------- diff -ru orig/rsync-2.5.6/generator.c rsync-2.5.6/generator.c ---

[ see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426191 ] The text in the description of the --append option may lead one to believe that files that are shorter on the receiving side won't be updated, due to the following text: ... Only files on the receiving side that are shorter than the corresponding file on the sending side (as well as new files) are sent. ... IMHO

Hi, A minor bug in the manpage was noticed by a Debian user... (Please keep the 418923-forwarded@bugs.debian.org in the Cc list in replies.) diff -u -r1.399 rsync.yo --- rsync.yo 23 Jan 2007 15:34:43 -0000 1.399 +++ rsync.yo 12 Apr 2007 19:30:17 -0000 @@ -724,7 +724,7 @@ also ignored. Using this option in conjunction with bf(--relative) may give unexpected results. -dit(bf(-K,

I just noticed, too late )-: --append This causes rsync to update a file by appending data onto the end of the file, which presumes that the data that already exists on the receiving side is identical with the start of the file on the sending side. Any files that are the same size or shorter on the

In the manpage, all occurrences of a single quote (or apostrophe) are preceded by a backslash. This means that these get turned into acute accents by groff; here's the relevant part of the groff manpage: \' The acute accent ; same as \(aa. Unescaped: apostrophe, right quotation mark, single quote (ASCII 0x27). I think all these backslashes should be removed, as the

There's a rather old bug report in Debian's bug tracking system (see http://bugs.debian.org/27126) about wanting to be able to specify the maximum file size, as well as the minimum file size. Here's the text: Sometimes, it's useful to specify a file size range one is interested in. For example, I'd like to keep an up-to-date mirror of Debian, but I currently

I'm sure that someone's gonna complain that parsing the output is messed up by this patch, but then they should have told about the typo themselves :-) --- log.c.orig 2004-08-17 10:25:57.000000000 +0200 +++ log.c 2004-09-05 16:28:42.000000000 +0200 @@ -61,7 +61,7 @@ { RERR_WAITCHILD , "some error returned by waitpid()" }, { RERR_MALLOC , "error allocating core

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

There is a small race condition in rsync 2.5.6. When the transfer is finished, and the file is moved into place, there is a short time period where the new file is in place with the wrong permissions. When using rsync on a busy email server to replace the exim config file with a new file, exim will produce several complaints in that short period. This small patch fixes the problem, by making

On Mon 07 Apr 2008, S.A. Birl wrote: > > Server is running rsync 2.6.1 on RH > Client is running rsync 2.6.3 on Cygwin (Win2003) > > When I connect client to server, I get kicked out after SSH > authentication. I can manually ssh into the server with no problems. Is the server running an rsync daemon? If so, why the ssh? Paul Slootman

The directory I'm trying to copy from is: /home/blah/dir The symlink is /home/blah/dir/unwanted_symlinked_dir On Fri, Mar 3, 2017 at 8:10 AM, Paul Slootman <paul+rsync at wurtel.net> wrote: > On Fri 03 Mar 2017, Steve Dondley wrote: > > > I'm trying to rsync a directory from a server to my local machine that > has > > a symbolic link to a directory I don't

rsync 2.5.6 security advisory ----------------------------- December 4th 2003 Background ---------- The rsync team has received evidence that a vulnerability in rsync was recently used in combination with a Linux kernel vulnerability to compromise the security of a public rsync server. While the forensic evidence we have is incomplete, we have pieced together the most likely way that this

Hi, I got the following report from a Debian user, about --files-from transferring the contents of a dir (i.e. including the files in it) specified in the input, even thugh the files aren't listed in the input. This happens only when the dir name ends with a slash. I asked him to cook up a script to reproduce this (as it wasn't quite clear to me at first what happened exactly). Any

rsync 2.5.6 security advisory ----------------------------- December 4th 2003 Background ---------- The rsync team has received evidence that a vulnerability in rsync was recently used in combination with a Linux kernel vulnerability to compromise the security of a public rsync server. While the forensic evidence we have is incomplete, we have pieced together the most likely way that this

>From the manpage: --csum-length=LENGTH By default the primary checksum used in rsync is a very strong 16 byte MD4 checksum. In most cases you will find that a trun- cated version of this checksum is quite efficient, and this will decrease the size of the checksum data sent over the link, mak- ing things faster. You can choose the

A trailing slash on a module name has no effect, which is on the one hand logical as it's not a directory name; on the other hand it's not consistent either (as experienced by a user). I suggest at least adding some comment to the manpage where trailing slashes are discussed. Perhaps also mention it in the rsyncd.conf manpage, where perhaps it may be noticed sooner. If I find the time

I wanted to restrict rsync to listen only on one IP address on a multi-homed system. I put an "address aa.bb.cc.dd" option in the (single) module definition, as the manpage shows that "address" is a module option, not a global one. However, lsof showed that rsync had bound to * instead of the specified IP address. Moving the "address" line to the global part did the

The manpage states: You may turn off one or more implied options by prefixing the option name with "no-". Not all options may be prefixed with a "no-": only options that are implied by other options (e.g. --no-D, --no-perms) or have different defaults in various circumstances (e.g. --no-whole-file, --no-blocking-io, --no-dirs). You may specify either

Am 14.11.19 um 10:54 schrieb Paul Slootman via rsync: > You need to specify the source directory as the link-dest directory. Hi, I tried it also because it's an old question which has never worked for me. Instead it creates copies and not hard links: pierre at in94:~/tmp$ ls -li a b a: insgesamt 8 257315 -rw-r--r-- 1 pierre pierre 4 Nov 14 10:53 1 257316 -rw-r--r-- 1 pierre pierre 6 Nov

There's a bug reported in Debian about the tty being screwed up by wierd filenames, see http://bugs.debian.org/bug=242300 On the one hand, find will also do this. On the other hand, ls will replace such chars with a question mark. Upon inspection, it appears to be fairly simple to also do this in rsync (in the rwrite() function). Here's a patch. Opinions? Perhaps don't do it