public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Rsync patch
@ 2000-04-24  7:10 Ville Herva
  2000-04-24 16:47 ` Corinna Vinschen
  0 siblings, 1 reply; 3+ messages in thread
From: Ville Herva @ 2000-04-24  7:10 UTC (permalink / raw)
  To: cygwin

Patch is available at http://v.iki.fi/~vherva/cygwin-rsync/

[I posted this to rsync mailing list a while a ago, but I think it might
interest somebody here as well. Comments welcome. ]

Rsync compiles cleanly for CYGWIN, but I found that while it compiles
cleanly out of the box (newest (almost) cygwin1.dll snapshot and
gcc-2.95.2), some tweaks are necessary to get most out of it. (2.4.3 was
only released during my tweaking so I've been lazy enough not to upgrade.
This patch is against 2.4.2).

Firstly, the only sensible way to run something as "daemon" under NT is to
run it as service. One can use SrvAny.exe from the NT resource kit for
this. However, as it is, rsync immediately forks another process, and net
stop has not desired effect, since srvany can't kill the rsync daemon. I
added --dont-fork option so rsync can be forced not to fork when run as
daemon. This way starting and stopping services works right.

Secondly, if I connect to rsync daemon from another machine and hit ctrl-c
at the client end during transfer, the rsync daemon exists (not just the
connection handler process, but every rsync). I guess this is because
rsync gets sigpipe signal, which is handled by sig_int, which in turn
sends sigusr to the parent. I have no idea why this should be. I changed
sigpipe handler to SIG_IGN, and I now get the behaviour I want: if there
is a network error (such as premature socket closing) the rysnc daemon
won't die, and I can reconnect to it. I didn't do this cleanly: the
connection handler process should in fact exit (perhaps after some clean
up), but not the parent. This is not a problem, however, since the parent
will reap the connection handler after a minute. Am I missing something
here, or why is sigpipe handled by sig_int?

Third, under CYGWIN, it makes little sense to force attribute check on the
password file. It can be made to work if env var CYGWIN contains "ntea"
(nt extended attribute mode -- CYGWIN emulates unix permissions through a
hack), but frankly, it is a MAJOR pain in the ass to get working
especially when trying to run rsync as a NT service. Besides, CYGWIN
permissions won't give you any added security -- the security should be
handled with NTFS ACL's. So I added a #ifndef __CYGWIN__'s around the
check.

Lastly, the original reason I began compiling my own version was that I
had a binary version that did not force binary open (I got corrupted .doc
files etc in the transmission.) I found out that the mainline rsync source
(as of 2.4.2) already has that O_BINARY bit in do_open, so no problem
here. It works without, if you mount everything with -b (binary) in
CYGWIN or force that with "set CYGWIN=BINMODE", but O_BINARY is the (most)
correct way to do it -- it works regardless how the user has mounted his
filesystems. However, if the mounts are binary, the configuration files
are not read right: if, for example, the user makes a password file with
notepad, he'll get an additional CR into the password (due to missing
CR/LF->LF conversion). So I added open(O_TEXT) forcing to every config
file open (#ifdef CYGWIN'ed, of course). Now the users shouldn't have to
worry about mount types.


-- v --

v@iki.fi

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Rsync patch
  2000-04-24  7:10 Rsync patch Ville Herva
@ 2000-04-24 16:47 ` Corinna Vinschen
  2000-04-25 12:43   ` Ville Herva
  0 siblings, 1 reply; 3+ messages in thread
From: Corinna Vinschen @ 2000-04-24 16:47 UTC (permalink / raw)
  To: Ville Herva; +Cc: cygwin

Ville Herva wrote:
> [...]
> Third, under CYGWIN, it makes little sense to force attribute check on the
> password file. It can be made to work if env var CYGWIN contains "ntea"
> (nt extended attribute mode -- CYGWIN emulates unix permissions through a
> hack), but frankly, it is a MAJOR pain in the ass to get working
> especially when trying to run rsync as a NT service. Besides, CYGWIN
> permissions won't give you any added security -- the security should be
> handled with NTFS ACL's. So I added a #ifndef __CYGWIN__'s around the
> check.

There's a CYGWIN setting named `ntsec' since the CD version 1.0.
It's using NTFS ACL's to implement POSIX security.

Corinna

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Rsync patch
  2000-04-24 16:47 ` Corinna Vinschen
@ 2000-04-25 12:43   ` Ville Herva
  0 siblings, 0 replies; 3+ messages in thread
From: Ville Herva @ 2000-04-25 12:43 UTC (permalink / raw)
  To: cygwin

On Tue, Apr 25, 2000 at 01:42:32AM +0200, you [Corinna Vinschen] claimed:
> Ville Herva wrote:
> > [...]
> > Third, under CYGWIN, it makes little sense to force attribute check on the
> > password file. It can be made to work if env var CYGWIN contains "ntea"
> > (nt extended attribute mode -- CYGWIN emulates unix permissions through a
> > hack), but frankly, it is a MAJOR pain in the ass to get working
> > especially when trying to run rsync as a NT service. Besides, CYGWIN
> > permissions won't give you any added security -- the security should be
> > handled with NTFS ACL's. So I added a #ifndef __CYGWIN__'s around the
> > check.
> 
> There's a CYGWIN setting named `ntsec' since the CD version 1.0.
> It's using NTFS ACL's to implement POSIX security.

Thanks, I wasn't aware of that. I'll check it. 


-- v --

v@iki.fi

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-04-25 12:43 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-24  7:10 Rsync patch Ville Herva
2000-04-24 16:47 ` Corinna Vinschen
2000-04-25 12:43   ` Ville Herva

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).