On Tue, 15 Feb 2005, david blunkett <[EMAIL PROTECTED]> wrote:
>
> The use chroot=no certainly has a beneficial effect because rsync has
> started to work again.
>
> Here is (probably) the interesting bit of the debugging output before:
> What seems to happen is that it chroots, builds the file l
Wayne,
The use chroot=no certainly has a beneficial effect because rsync has
started to work again.
Here is (probably) the interesting bit of the debugging output before:
What seems to happen is that it chroots, builds the file list and then tries
to open all sorts of stuff that is impossible on
On Tue, Feb 15, 2005 at 02:33:56PM +, david blunkett wrote:
> I don't think my daemon is chrooting but I don't undestand how this is
> controlled so I can't be sure,
It uses chroot by default unless "use chroot = no" is placed in the
rsyncd.conf file that your daemon is reading (which is ofte
On Tue, Feb 15, 2005 at 10:20:56AM +0100, ?yvin S?mme wrote:
> 3) How will it work with the '-n' option?
With -n, rsync will tell you about the files that it would transfer (as
normal) and no files would be deleted. It would also skip the "sender
removed X" messages that are output for -vv when t
We got your request and created a new ticket.
Ticket ID: [DHK-82963-996]
Subject: Hokki =)
One of our staff members will review it and get back to you soon.
Thank you!
Nessoft, LLC
You can check the status of this ticket by logging in to our support system at:
http://www.nessoft.com/support
Per my comment yesterday:
> However, I just kicked off another parametric study varying the rsync block
> size and the block mask size, while holding the window size constant. If
> there is an optimization avaialble for rsync block size, then we should see a
> dependency in these
results.
T
Try running without the compression option (-z) to see if that 'fixes'
the problem. Your previous rsync may have used a static compression
routine, and FC2 uses a dynamic one. Just a guess...
The first rsync to delete the directory is successful because since it
does no file transfers, no compre
Has anyone been able to get rsync running on Windows 2003?
I had it running on Windows NT, but ever since I installed it on Windows 2003,
it is not working. I am getting "Failed to connect to... Connection refused."
There is absolutely no change in rsync config and rsync binary between NT &
200
On Tue, 15 Feb 2005, david blunkett <[EMAIL PROTECTED]> wrote:
>
> [pid 27864] stat64("/usr/lib/i686", 0xfef74ac8) = -1 ENOENT (No such file or
> directory)
> [pid 27864] open("/usr/lib/libnss_compat.so.2", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> [pid 27864] stat64("/usr/lib", 0xfef7
Hi,
Is there a possibility to log deletes as well when using the --log-format
parameter? Currently I use --log-format='[%%t] %%o %%f' under win32 instead
of -v. This works nice for all files being transfered, but doesn't log any
deletes.
Thanks,
Joost
--
To unsubscribe or change options: htt
Wayne,
I am running an rsyncd on my backup host - I now think the problem is NOT
the firewall (complicated: originally port 873 was blocked elsewhere). Now
I get the same problem with or without the firewall and at the client end I
get this:
rsync: connection unexpectedly closed (196 bytes rea
I have not yet tried your patch but:
1) The patch you describe sounds ideal to me
2) I hope you will include it in the next main release
3) How will it work with the '-n' option?
Thanks
Wayne Davison wrote:
On Mon, Feb 14, 2005 at 02:03:56PM +0100, ?yvin S?mme wrote:
I would like an option that del
12 matches
Mail list logo
