Re: Status of upcoming 2.6.0 release

[Paul Slootman]

I just noticed this in the rsyncd.conf manpage:

.SH "VERSION"
This man page is current for version 2\&.0 of rsync

I'm sure that this can be updated to 2.6.0 :-)


Paul Slootman
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Resource(s) in use

[Michal Gronkowski]

Hi,
I am trying to sync 50Gb volume using Rsync 2.5.5, but get random errors
like this one:
"rename Skala/Plus/Kubek/.Kubas3.psd.001742 ->
Skala/Plus/Kubek/Kubas3.psd : Resource(s) in use".
Every rsync session the files which are "in use" are different.
There is no other activity than rsync on rsync server (no files should be
opened).
It looks like rsync client is stacked after such an error occurs.
Any suggestions ?
Michal

-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Does rsync/cygwin hanging problem be solved?

[Wayne Davison]

The rsync-on-cygwin hang problem looks like it will be fixed in the next
cygwin release by their fixing a bug in cygwin's signal handling.  In
the meantime, there is a cygwin-specific version that has a patch that
tries to kludge around the problem.  Others who actually use the cygwin
version will have to fill in the details for you, as I don't know them.

..wayne..
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Does rsync/cygwin hanging problem be solved?

[John Hunt]

On Monday 29 Dec 2003 3:52 am, Zhang, Zhenhua wrote:
>  I am new user  of rsync.
>  I notice rsync will hang under cygwin when transfering files
> occasionally, then I see the mail archieve discussing this problem at
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg08726.html
>  Does this bugs has been fixed?
>  Anyone can give me an answer? thanks.
>
> Best Regards

There is a version at http://itefix.no/cwrsync/ that does work. (The fix is in 
the cygwin1.dll in this package, not in rsync which afair is standard 2.5.7 
version.)

-- 

John Hunt
Stokesley, N Yorks, UK
e-mail: [EMAIL PROTECTED]
URL: http://www.yoredale.uklinux.net/


-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Question about file ownership on destination

[acct svcs]

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 server. I do want to preserve the 
actual ownership. How can I ensure this is done?

Here's an example of my configuration:

rsyncd.conf on 192.168.1.1:

log file = /var/log/rsyncd.log
max connections = 4
#redundant chroot since this is the default, but just to be sure...
use chroot = yes
[server1]
   path = /netdisk/server1/mirror
   comment = server1 Server Root
   list = no
   read only = no
	auth users = server1server
	secrets file = /root/rsync-passwd
	hosts allow = 192.168.100.1
#note that the uid and gid belong to a non-privileged linux user "server1" 
on this host
	uid = server1
	gid = server1

##

I run this from Server1:
rsync -av --delete --sparse --exclude="rsync-mirror.sh" --exclude="/proc/" 
--exclude="/tmp/" --exclude="/mnt/" --exclude="/dev/" --exclude="/backup/" 
--exclude="/backup2/" / [EMAIL PROTECTED]::server1/

I'm using rsync 2.5.7 protocol version 2.6

TIA

Joe

_
Working moms: Find helpful tips here on managing kids, home, work —  and 
yourself.   http://special.msn.com/msnbc/workingmom.armx

--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Question about file ownership on destination

[Wayne Davison]

On Mon, Dec 29, 2003 at 01:19:06PM -0500, acct svcs wrote:
> 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 server.

Which is the user you told rsync to run as.  If you want any other
user(s) to own the files, you have to tell it to run as root.

..wayne..
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Is this correct?

[kevin_david_carpenter]

I am trying to copy an 8 gig file. After first copying it over I try 
and rsync it again. There are no changes so why is it copying the 
file over again? Here is the output of what I am trying to do. And 
what does speedup mean?

[EMAIL PROTECTED] Storage]# rsync --verbose --recursive -t --stats --
progress ntapps.dsk vmware2::home/
[EMAIL PROTECTED] Storage]# rsync --verbose --recursive -t --stats --
progress ntapps.
building file list ...
1 file to consider
ntapps.dsk
  8388608512 100%2.11MB/s1:03:11
rsync[8049] (sender) heap statistics:
  arena: 147992   (bytes from sbrk)
  ordblks:3   (chunks not in use)
  smblks: 0
  hblks:  0   (chunks from mmap)
  hblkhd: 0   (bytes from mmap)
  usmblks:0
  fsmblks:0
  uordblks:   42648   (bytes used)
  fordblks:  105344   (bytes free)
  keepcost:   11168   (bytes in releasable chunk)

Number of files: 1
Number of files transferred: 1
Total file size: 8388608512 bytes
Total transferred file size: 8388608512 bytes
Literal data: 8388608512 bytes
Matched data: 0 bytes
File list size: 37
Total bytes written: 8389632637
Total bytes read: 56

wrote 8389632637 bytes  read 56 bytes  2212164.19 bytes/sec
total size is 8388608512  speedup is 1.00

[EMAIL PROTECTED] Storage]# rsync --verbose --recursive -t --stats --
progress ntapps.dsk vmware2::home/
building file list ...
1 file to consider
ntapps.dsk
  8388608512 100%2.35MB/s0:56:40
rsync[8820] (sender) heap statistics:
  arena: 147992   (bytes from sbrk)
  ordblks:5   (chunks not in use)
  smblks: 0
  hblks:  1   (chunks from mmap)
  hblkhd:266240   (bytes from mmap)
  usmblks:0
  fsmblks:0
  uordblks:   59056   (bytes used)
  fordblks:   88936   (bytes free)
  keepcost:   11168   (bytes in releasable chunk)

Number of files: 1
Number of files transferred: 1
Total file size: 8388608512 bytes
Total transferred file size: 8388608512 bytes
Literal data: 0 bytes
Matched data: 8388608512 bytes
File list size: 37
Total bytes written: 2048125
Total bytes read: 3072062

wrote 2048125 bytes  read 3072062 bytes  1307.67 bytes/sec
total size is 8388608512  speedup is 1638.34

-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

The dangers of static buffers in rsync code

[Cristian Gafton]

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 possibly other issues as well, but
hardlinks is what made me look deeper inside the rsync code.

As a side note, the f_name function has some "protection" against this
static clobbering: instead of having a single buffer, it has... TEN, and
it cycles through them. That's both funny and sad...

One obvious problem path is starting from generator.c:generate_files()  
function. In there we call in a while loop:

recv_generator(local_name?local_name:f_name(file),flist,i,f), which calls
  hlink.c:check_hard_link(), which calls
hlink.c:hlink_compare(), which calls
  flist.c:file_compare(), which calls
flist.c:f_name().

Interested parties might want to follow the code, it is easier and more
obvious...

Anyway, the end result is that in recv_generator() the first argument 
(fname) is now clobbered by our search through the hlink_list, and 
depending on what was the last thing we put in there there are various 
failures happening.

The bad part is that they are mostly silent. Most of the bitching is done
via "if (verbose > 1)", so with the standard 'rsync -av' there are no
indicators that would tell somebody rsync failed to handle a particular
file...

One way of "unclobbering" this is by forcing another call to f_name after
the check_hard_link() call is finished (wither in check_hard_link itself
or in recv_generator), but that smells rather nasty... On the other hand,
reimplementing f_name to make it sane would require some bigger changes,
since f_name() happens to be quite a popular function inside the rsync
code...

This is bad and needs some fixing... Little hammer or big hammer?

Cristian
--
--
Cristian Gafton -- [EMAIL PROTECTED]  -- Red Hat, Inc.
~~
  "There are two kinds of people who never amount to much: those who 
   cannot do what they are told, and those who can do nothing else."
--Cyrus Curtis



-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Question about file ownership on destination

[acct svcs]

Wayne,

AFAIK, the daemon is running as root.  Thjs is how I set it up under xinetd. 
 As I understand it, in order for the chroot to work, it has to be root. 
This is also evidenced by the fact that it is running on  rsync's default 
port which is under 1024.

Joe



From: Wayne Davison <[EMAIL PROTECTED]>
To: acct svcs <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: Question about file ownership on destination
Date: Mon, 29 Dec 2003 11:05:41 -0800
MIME-Version: 1.0
Received: from binome.blorf.net ([216.228.9.89]) by mc12-f8.hotmail.com 
with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Dec 2003 11:05:41 -0800
Received: by binome.blorf.net (Postfix, from userid 1000)id B6CCF2FA8; Mon, 
29 Dec 2003 11:05:41 -0800 (PST)
X-Message-Info: JGTYoYF78jFGhKOcwUQ2Qs4xZ7apiUOc
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.5.4i
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 29 Dec 2003 19:05:41.0208 (UTC) 
FILETIME=[C0A8AD80:01C3CE3E]

On Mon, Dec 29, 2003 at 01:19:06PM -0500, acct svcs wrote:
> 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 server.
Which is the user you told rsync to run as.  If you want any other
user(s) to own the files, you have to tell it to run as root.
..wayne..
_
Make your home warm and cozy this winter with tips from MSN House & Home.  
http://special.msn.com/home/warmhome.armx

--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: The dangers of static buffers in rsync code

[jw schultz]

On Mon, Dec 29, 2003 at 04:55:19PM -0500, Cristian Gafton wrote:
> 
> 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 possibly other issues as well, but
> hardlinks is what made me look deeper inside the rsync code.
> 
> As a side note, the f_name function has some "protection" against this
> static clobbering: instead of having a single buffer, it has... TEN, and
> it cycles through them. That's both funny and sad...
> 
> One obvious problem path is starting from generator.c:generate_files()  
> function. In there we call in a while loop:
> 
> recv_generator(local_name?local_name:f_name(file),flist,i,f), which calls
>   hlink.c:check_hard_link(), which calls
> hlink.c:hlink_compare(), which calls
>   flist.c:file_compare(), which calls
> flist.c:f_name().
> 
> Interested parties might want to follow the code, it is easier and more
> obvious...
> 
> Anyway, the end result is that in recv_generator() the first argument 
> (fname) is now clobbered by our search through the hlink_list, and 
> depending on what was the last thing we put in there there are various 
> failures happening.
> 
> The bad part is that they are mostly silent. Most of the bitching is done
> via "if (verbose > 1)", so with the standard 'rsync -av' there are no
> indicators that would tell somebody rsync failed to handle a particular
> file...
> 
> One way of "unclobbering" this is by forcing another call to f_name after
> the check_hard_link() call is finished (wither in check_hard_link itself
> or in recv_generator), but that smells rather nasty... On the other hand,
> reimplementing f_name to make it sane would require some bigger changes,
> since f_name() happens to be quite a popular function inside the rsync
> code...
> 
> This is bad and needs some fixing... Little hammer or big hammer?

How about an even smaller hammer.
In recv_generator do a strlcpy of arg1 to an automatic.

-- 

J.W. SchultzPegasystems Technologies
email address:  [EMAIL PROTECTED]

Remember Cernan and Schmitt
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Question about file ownership on destination

[Wayne Davison]

On Mon, Dec 29, 2003 at 05:23:21PM -0500, acct svcs wrote:
> AFAIK, the daemon is running as root.

Quoting from the rsyncd.conf file you cited:

uid = server1
gid = server1

Comment-out these lines.

..wayne..
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

rsync 2.5.7 link-dest seems broken

[gname]

Hi --

I'm experiencing problems when using rsync between two different machines.
Details follows:

Both machines are running 2.4.23, rsync versions on both are identically
configured versions of 2.5.7:

rsync  version 2.5.7  protocol version 26
Copyright (C) 1996-2002 by Andrew Tridgell and others

Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles, 
  IPv6, 64-bit system inums, 64-bit internal inums


I'm using rsync across ssh in all cases.

If i use --link-dest to copy/link a directory tree from hosta -> hosta (over
ssh) this will work, files will be copied and linked.  Between hostb -> hostb
also works, files will be copied and linked. hosta -> hostb or vice versa
doesn't work. 

In the latter case rsync reports a speed up, so i presume it is using some of
the existing content to optimize network usage.  However the speed up is very
much lower than in the first two cases.

AFAICT rsync should use numeric id's only when requested, and the user and
group name combinations are identical on both sides.

-- 
He spoke. And drank rapidly a glass of water

-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Question about file ownership on destination

[jw schultz]

On Mon, Dec 29, 2003 at 03:26:53PM -0800, Wayne Davison wrote:
> On Mon, Dec 29, 2003 at 05:23:21PM -0500, acct svcs wrote:
> > AFAIK, the daemon is running as root.
> 
> Quoting from the rsyncd.conf file you cited:
> 
> uid = server1
>   gid = server1
> 
> Comment-out these lines.

He is also running with use chroot = true so commenting out
the uid = server1 will have the daemon running as nobody.

uid = 0
gid = 0

is what he wants.

-- 

J.W. SchultzPegasystems Technologies
email address:  [EMAIL PROTECTED]

Remember Cernan and Schmitt
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: rsync 2.5.7 link-dest seems broken

[jw schultz]

On Tue, Dec 30, 2003 at 12:27:21AM +, [EMAIL PROTECTED] wrote:
> 
> Hi --
> 
> I'm experiencing problems when using rsync between two different machines.
> Details follows:
> 
> Both machines are running 2.4.23, rsync versions on both are identically
> configured versions of 2.5.7:
> 
> rsync  version 2.5.7  protocol version 26
> Copyright (C) 1996-2002 by Andrew Tridgell and others
> 
> Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles, 
>   IPv6, 64-bit system inums, 64-bit internal inums
> 
> 
> I'm using rsync across ssh in all cases.
> 
> If i use --link-dest to copy/link a directory tree from hosta -> hosta (over
> ssh) this will work, files will be copied and linked.  Between hostb -> hostb
> also works, files will be copied and linked. hosta -> hostb or vice versa
> doesn't work. 
> 
> In the latter case rsync reports a speed up, so i presume it is using some of
> the existing content to optimize network usage.  However the speed up is very
> much lower than in the first two cases.
> 
> AFAICT rsync should use numeric id's only when requested, and the user and
> group name combinations are identical on both sides.

Since you don't show command lines i cannot comment.

-- 

J.W. SchultzPegasystems Technologies
email address:  [EMAIL PROTECTED]

Remember Cernan and Schmitt
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Unchanged file recopied + meaning of speedup (was: Is this correct?)

[John Van Essen]

(I changed the Subject to something less generic...)

On Mon, 29 Dec 2003, kevin_david_carpenter <[EMAIL PROTECTED]> wrote:
>
> I am trying to copy an 8 gig file. After first copying it over I try
> and rsync it again. There are no changes so why is it copying the
> file over again? Here is the output of what I am trying to do. And
> what does speedup mean?

See the --modify-window option.  It may apply in your case.

The speedup value is the ratio of total size to sum of bytes read and
written.  It represents the savings in I/O from rsync's intelligent
synchronization where it (by default) transfers a file only if it does
not exist on the receiver, or does exist but has a different size or
timestamp (and in those cases it can compare block checksums to avoid
copying unchanged portions of a file).

The speedup value is roughly the multiplier to apply to the number of
actual bytes tranferred to get the number of bytes that a really dumb
"full file, every file" synchronization would have transferred.

On an initial rsync, the speedup will be near 1.00 (no speedup).
Subsequent rsyncs will have speedups that depend on how much data had
to be copied.  Note that in your second transfer, where it did have to
resend the file, it was able to match all 8 GB of data and transferred
only a small fraction of that in matching checksum values.  Hence a
speedup of 1600+.
-- 
John Van Essen  Univ of MN Alumnus  <[EMAIL PROTECTED]>



> [EMAIL PROTECTED] Storage]# rsync --verbose --recursive -t --stats --
> progress ntapps.dsk vmware2::home/
> [EMAIL PROTECTED] Storage]# rsync --verbose --recursive -t --stats --
> progress ntapps.
> building file list ...
> 1 file to consider
> ntapps.dsk
>   8388608512 100%2.11MB/s1:03:11
> rsync[8049] (sender) heap statistics:
>   arena: 147992   (bytes from sbrk)
>   ordblks:3   (chunks not in use)
>   smblks: 0
>   hblks:  0   (chunks from mmap)
>   hblkhd: 0   (bytes from mmap)
>   usmblks:0
>   fsmblks:0
>   uordblks:   42648   (bytes used)
>   fordblks:  105344   (bytes free)
>   keepcost:   11168   (bytes in releasable chunk)
> 
> Number of files: 1
> Number of files transferred: 1
> Total file size: 8388608512 bytes
> Total transferred file size: 8388608512 bytes
> Literal data: 8388608512 bytes
> Matched data: 0 bytes
> File list size: 37
> Total bytes written: 8389632637
> Total bytes read: 56
> 
> wrote 8389632637 bytes  read 56 bytes  2212164.19 bytes/sec
> total size is 8388608512  speedup is 1.00
> 
> [EMAIL PROTECTED] Storage]# rsync --verbose --recursive -t --stats --
> progress ntapps.dsk vmware2::home/
> building file list ...
> 1 file to consider
> ntapps.dsk
>   8388608512 100%2.35MB/s0:56:40
> rsync[8820] (sender) heap statistics:
>   arena: 147992   (bytes from sbrk)
>   ordblks:5   (chunks not in use)
>   smblks: 0
>   hblks:  1   (chunks from mmap)
>   hblkhd:266240   (bytes from mmap)
>   usmblks:0
>   fsmblks:0
>   uordblks:   59056   (bytes used)
>   fordblks:   88936   (bytes free)
>   keepcost:   11168   (bytes in releasable chunk)
> 
> Number of files: 1
> Number of files transferred: 1
> Total file size: 8388608512 bytes
> Total transferred file size: 8388608512 bytes
> Literal data: 0 bytes
> Matched data: 8388608512 bytes
> File list size: 37
> Total bytes written: 2048125
> Total bytes read: 3072062
> 
> wrote 2048125 bytes  read 3072062 bytes  1307.67 bytes/sec
> total size is 8388608512  speedup is 1638.34

-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Status of upcoming 2.6.0 release

[John Poltorak]

On Sun, Dec 28, 2003 at 01:32:53PM -0800, Wayne Davison wrote:
> The changes made to 2.6.0pre1 have been pretty minor so far, so I had
> been debating whether we needed a pre2 release or not.  I finally
> decided to go ahead and release what little there is, just to give
> folks a final opportunity to double check the final release:
> 
> 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
> 
> http://samba.org/ftp/rsync/preview/patches/rsync-2.6.0pre1-2.6.0pre2.diffs.gz
> http://samba.org/ftp/rsync/preview/patches/rsync-2.6.0pre1-2.6.0pre2.diffs.gz.sig
> 
> My current plan is to release 2.6.0 final on January 1st, barring any
> unforeseen complications.  Let me know if you run into any problems, or
> have comments, questions, or concerns.  Thanks,

Is there any chance of including [EMAIL PROTECTED]@  in Makefile.in?

This would enable it to build more easily on OS/2 without jumping through 
numerous hoops.


> 
> ..wayne..


-- 
John


-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: The dangers of static buffers in rsync code

[Wayne Davison]

On Mon, Dec 29, 2003 at 04:55:19PM -0500, Cristian Gafton wrote:
> 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?

It's fairly handy for short-lived stuff, such as a printf() statement
that need two f_name() values.  However, as you noted, for long-lived
stuff, it is an accident waiting to happen.

> This is bad and needs some fixing... Little hammer or big hammer?

I'm inclined to go with the big hammer for the next release (after
2.6.0).  The f_name() function is labeled as one of the biggest hot
spots in the code, so optimizing it to allow an expansion into a
local buffer should make it both safer and faster (one section of the
code currently uses strdup() to protect the f_name() value -- ick).
Also, optimizing the string-compare case to avoid copying would
probably be a win as well.  I've got some code that takes a stab at
doing this:

http://www.blorf.net/rsync-big-hammer.patch

It's been only minimally tested, so use it either as an indicator of
what I'm currently considering for post-2.6.0, or feel free to help
test it.

..wayne..
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Status of upcoming 2.6.0 release

[Wayne Davison]

On Tue, Dec 30, 2003 at 02:04:47AM +, John Poltorak wrote:
> Is there any chance of including [EMAIL PROTECTED]@  in Makefile.in?

I committed that change last January, so it should already be in the
2.5.6 and 2.5.7 releases.

..wayne..
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: The dangers of static buffers in rsync code

[Cristian Gafton]

On Mon, 29 Dec 2003, jw schultz wrote:

> How about an even smaller hammer.
> In recv_generator do a strlcpy of arg1 to an automatic.

That would work for this aprticular case I explained - however, the fact 
is that f_name() can change the value of the arguments passed around 
inhigher level functions, and there is no idication whatsoever when this 
is expected, when we don't care and when we mean "Oops!".

It is a nasty trap, and if you agree that it should get fixed, I think it 
is better done as part of the 2.6.0 rollout than at some minor release in 
the future.

Cristian
--
--
Cristian Gafton -- [EMAIL PROTECTED]  -- Red Hat, Inc.
~~
  "There are two kinds of people who never amount to much: those who 
   cannot do what they are told, and those who can do nothing else."
--Cyrus Curtis

-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: The dangers of static buffers in rsync code

[Jim Salter]

Fie on you, sir (although I mean that in the nicest possible way) - I'd 
like to see 2.6.0 get its head out the door. =)

Jim Salter

> Cristian Gafton wrote:
It is a nasty trap, and if you agree that it should get fixed, I think it 
is better done as part of the 2.6.0 rollout than at some minor release in 
the future.
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Question about file ownership on destination

[acct svcs]

Wayne

Actually, I tried that earlier and it didn't work.  The connection 
terminates unexpectedly almost immediately after the process begins.  Rsyncd 
uses user nobody by default, and that user can't create the files on the 
server.  That would work perfectly if the server was the source, but in my 
case it's the destination.

After your suggestion I did discover a solution, though.  I had to 
explicitly assign uid and gid to root in rsyncd.conf (hmmm, security?).   
Well, I have also restricted the allowed hosts and the segment is behind a 
firewall that filters the rsyncd port, so it should be reasonably secure.

Thanks for helping out Wayne.

joe


From: Wayne Davison <[EMAIL PROTECTED]>
To: acct svcs <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: Question about file ownership on destination
Date: Mon, 29 Dec 2003 15:26:53 -0800
MIME-Version: 1.0
Received: from binome.blorf.net ([216.228.9.89]) by mc10-f41.hotmail.com 
with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Dec 2003 15:26:53 -0800
Received: by binome.blorf.net (Postfix, from userid 1000)id 93EA62FA3; Mon, 
29 Dec 2003 15:26:53 -0800 (PST)
X-Message-Info: JGTYoYF78jH5atsNlNatiOZjTbY+656T
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.5.4i
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 29 Dec 2003 23:26:53.0192 (UTC) 
FILETIME=[3DE3A880:01C3CE63]

On Mon, Dec 29, 2003 at 05:23:21PM -0500, acct svcs wrote:
> AFAIK, the daemon is running as root.
Quoting from the rsyncd.conf file you cited:

uid = server1
gid = server1
Comment-out these lines.

..wayne..
_
Make your home warm and cozy this winter with tips from MSN House & Home.  
http://special.msn.com/home/warmhome.armx

--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Question about file ownership on destination

[Jim Salter]

I'm not sure how that could be considered a security issue on rsync's 
part - if rsync wasn't running as root, how would it be able to set uid 
and gid arbitrarily?

> acct svcs wrote:
After your suggestion I did discover a solution, though.  I had to 
explicitly assign uid and gid to root in rsyncd.conf (hmmm, 
security?).
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Shorten long lines in man page options summary

[John Van Essen]

One thing that's bugged me is that some of the man page lines in the
options summary are longer than 79 chars and wrap onto the next line.

These are just one line summaries (detailed description appear later)
so they can, and should, be terse.

Here's an edited diff showing my proposed changes (and a 79 char ruler):

-1234567890123456789012345678901234567890123456789012345678901234567890123456789

---suffix=SUFFIX define backup suffix (default ~ w/o --backup-dir)
+--suffix=SUFFIX backup suffix (default ~ w/o --backup-dir)
 
---ignore-existing   ignore files that already exist on the receiving 
side
+--ignore-existing   ignore files already present on receiver
 
---deletedelete files that don't exist on the sending side
+--deletedelete files that don´t exist on sender
 
---delete-excluded   also delete excluded files on the receiving side
+--delete-excluded   also delete excluded files on receiver

---force force deletion of directories even if not empty
+--force delete directories even if not empty
 
--I, --ignore-times  don't exclude files that match length and time
+-I, --ignore-times  ignore mod time (ignore file size, also)
 
---size-only only use file size when determining if a file 
should be transferred
+--size-only ignore mod time (only compare file size)
 
---modify-window=NUM Timestamp window (seconds) for file match 
(default=0)
+--modify-window=NUM window (+/- seconds) for mod time match

---compare-dest=DIR  also compare destination files relative to DIR
+--compare-dest=DIR  also compare files relative to DIR

--0  --from0 file names we read are separated by nulls, not 
newlines
+-0  --from0 file list delimited by nulls, not newlines


Comments?  Suggestions?

Since this doesn't involve executable code, can this get into 2.6.0
(without another "pre" release)?
-- 
John Van Essen  Univ of MN Alumnus  <[EMAIL PROTECTED]>

-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Shorten long lines in man page options summary

[Chuck Wolber]

> One thing that's bugged me is that some of the man page lines in the
> options summary are longer than 79 chars and wrap onto the next line.

%< SNIP $< SNIP

> Comments?  Suggestions?

I second your point. It's a real pain in the butt to be in a noisy
datacenter at 4am with nothing but a console when you're trying to
decipher a man page that's wrapping.

-Chuck


-- 
Quantum Linux Laboratories - ACCELERATING Business with Open Technology
   * Education  | -=^ Ad Astra Per Aspera ^=-
   * Integration| http://www.quantumlinux.com
   * Support| [EMAIL PROTECTED]

"You know what you get after putting 30 years into a company? You're
 looking at it." -Downsized CIO of a major insurance carrier.

-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html