On Thu, May 08, 2008 at 09:34:07PM -0400, Matt McCutchen wrote:
This is to continue my discussion with Carl [...] about whether
no-tweak mode should become rsync's default when --inplace is not
specified.
I completely reject this idea. The --inplace option is all about data
updating, not
On an i686 with glibc 2.5 installed I'm not able to compile rsync 3.0.2
and later. rsync 3.0.0 was no problem, this compiled. Also on an x86_64
with glibc 2.7 installed rsync compiled.
Here is a script of the failing comilation:
Script started on Sat May 10 07:33:39 2008
[EMAIL PROTECTED]
On Thu, May 08, 2008 at 05:08:05PM -0700, Carl E. Thompson wrote:
If this is the desired behavior of --inplace then the documentation
is misleading at best.
Yes, the documention of that option was unclear that it was talking
about an update for a transferred file. I've checked-in some
On Sat, May 10, 2008 at 08:15:58AM +0200, Dominik Mahrer (Teddy) wrote:
/usr/include/compat.h:22:2: warning: #warning This header is obsolete, use
ap_compat.h instead
/tmp/ccHr5d51.s: Assembler messages:
/tmp/ccHr5d51.s:1409: Error: symbol `fstatat64' is already defined [...]
You might want
On Fri, May 09, 2008 at 09:06:02AM -0400, Robert DuToit wrote:
I havn't compiled 3.0.3 pre1 yet but have been seeing considerable longer
backup times on OSX 5.2, using 3.0.2 over 3.0.1.
There is nothing in the changes for 3.0.2 would affect rsync's speed.
Perhaps the patches you applied differ
On Thu, May 08, 2008 at 08:59:41AM -0700, arguellodw wrote:
rsync error: timeout in data send/receive (code 30) at
/home/lapo/packaging/tmp/rsync-2.6.3/io.c(153)
You are reaching your idle-time timeout. Either make it larger (e.g.
--timeout=360) or upgrade to a newer rsync version that has
https://bugzilla.samba.org/show_bug.cgi?id=5455
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from
https://bugzilla.samba.org/show_bug.cgi?id=5455
--- Comment #2 from [EMAIL PROTECTED] 2008-05-10 10:31 CST ---
One other question: have you modified the meaning of -E (using a popt alias)?
Because -E in 3.0.2 doesn't mean what it means in an Apple-modified rsync (a
stock rsync uses
On Tue, May 06, 2008 at 06:27:27PM -0700, Patrick Nolan wrote:
I thought the -q option and the redirection to /dev/null would
keep it quiet under normal circumstances. Apparently not.
It should. You shouldn't even require -q since you're not using -v.
I tried out your setup, and didn't get
Original Message
Subject: Re: Should no-tweak mode become the default?
From: Wayne Davison [EMAIL PROTECTED]
To: Matt McCutchen [EMAIL PROTECTED]
Date: 05/09/2008 11:25 PM
On Thu, May 08, 2008 at 09:34:07PM -0400, Matt McCutchen wrote:
This is to continue my discussion with
On Sat 10 May 2008, Carl E. Thompson wrote:
The reason I wanted the default changed is because it would
automatically fix current backup systems that are vulnerable to this
problem without all the vulnerable folks out there having to update all
of their software and settings (just the rsync
https://bugzilla.samba.org/show_bug.cgi?id=5455
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
On Sat, 2008-05-10 at 10:13 -0700, Carl E. Thompson wrote:
Truly, though,
it's not really a problem in rsync but in the backup systems that made
the assumption that rsync's default behavior is appropriate for the job
they are giving it.
My view exactly.
If the default won't be changed then
On Sat, 2008-05-10 at 21:04 +0200, Paul Slootman wrote:
A backup system should at the least ensure that the last version is
correct. If it has to tweak the attributes to do that, it should.
No one is considering leaving the last version incorrect. The
no-tweak mode replaces the destination
Original Message
Subject: Re: Should no-tweak mode become the default?
From: Paul Slootman [EMAIL PROTECTED]
To: rsync@lists.samba.org
Date: 05/10/2008 12:04 PM
...
My two cents...
A backup system should at the least ensure that the last version is
correct. If it has to
On Sat, 2008-05-10 at 15:22 -0700, Carl E. Thompson wrote:
--link-dest introduces other security problems itself which I have
already discussed at length.
I guess you're referring to item 2 in your original description of bug
5448? Item 2a would be solved by the daemon link-dest parameter that
https://bugzilla.samba.org/show_bug.cgi?id=5457
Summary: Add a client-side --munge-symlinks option
Product: rsync
Version: 3.0.3
Platform: Other
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P3
https://bugzilla.samba.org/show_bug.cgi?id=5458
Summary: -a -X throws error when processing fifo, even if --no-D
is specified
Product: rsync
Version: 3.0.1
Platform: x86
OS/Version: Mac OS X
Status: NEW
https://bugzilla.samba.org/show_bug.cgi?id=5458
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project rsync.
The branch, master has been updated
via adc4ebdd76cf98aacbe87b9664dd291199294297 (commit)
from
20 matches
Mail list logo
