Hopefully the email to the announce list will show up soon. Until then,
you can get a jump on the rest by checking out the rsync home page to
read the announcement:
http://rsync.samba.org/
It includes a security note about a fix that affects read/write daemons
that are not using chroot. If
As I alluded to in an earlier email on the subject of excludes, I had
the idea of allowing a merge idiom (think #include in C) inside
rsync's current exclude/include system. The idea is simple -- use the
prefix . (dot space) in front of a filename, and that file will be
incorporated into the
(As I was composing this, the 2.6.1 release notice on the rsync
list rolled in. The quoted source, below, hasn't changed, so
I'll leave the 'pre-1' references unchanged...)
I have a situation where an error message seems to be sent from
the daemon to the client, but none is logged in the
Rsync version 2.6.1 has been released. It is primarily a performance
release that requires less memory to run, makes fewer write calls to
the socket (lowering the system CPU time), does less string copying
(lowering the user CPU time), and also reduces the amount of data
that is transmitted over
Wayne,
Thanks for putting this into the CVS tree. I like your improvements.
-John
On Mon, Apr 26, 2004 at 08:10:50PM -0700, Wayne Davison wrote:
On Thu, Apr 22, 2004 at 04:20:07PM -0400, John Taylor wrote:
Upon a suggestion to improve the --timelimit patch, I have also added
a
On Mon, 26 Apr 2004, Wayne Davison wrote:
CVS now has an updated time-limit.diff patch in which I simplified the
code quite a bit and tweaked the options a bit:
Those are really nice new options.
[EMAIL PROTECTED]:MM
This option allows you to specify at what time to stop rsync, in
On Mon 26 Apr 2004, Wayne Davison wrote:
It includes a security note about a fix that affects read/write daemons
that are not using chroot. If that includes you, you should look into
upgrading (or maybe enabling chroot on an older rsync).
Is it possible to find the patches responsible for
On Tue 27 Apr 2004, Jon Jensen wrote:
[EMAIL PROTECTED]:MM
This option allows you to specify at what time to stop rsync, in
[EMAIL PROTECTED]:minute numeric format (e.g. [EMAIL PROTECTED]:59).
Is there any reason to use a nonstandard date/time format like this? The
Hi,
I have to parse log file in php script.I want to know exactly file by file if they
were transfered good or if they were an error or if nothing was done.
-- So i've use rsync with the option -vv and i can obtain something like this :
delta transmission enabled
send_files failed to open
Hi folks,
I'm maintaining the darwinports port of rsync and I encountered the
following strange thing:
I updated our port which contains a md5 checksum on 27. April 16:36 GMT.
Then some people had successfull builds (meaning the checksum was
valid). But now its
not anymore, it changed. I had a
[EMAIL PROTECTED] wrote:
Rsync version 2.6.1 has been released. It is primarily a performance
release that requires less memory to run, makes fewer write calls to
the socket (lowering the system CPU time), does less string copying
(lowering the user CPU time), and also reduces the amount of
Markus,
I am seeing the exact same thing, same two checksums.
The earlier file has size of 511412 and the latter 511395.
Here is the difference:
diff -urN rsync-2.6.1_early/util.c rsync-2.6.1_late/util.c
--- rsync-2.6.1_early/util.c2004-04-22 18:17:15.0 -0400
+++
hi.
return value of close() (receiver.c) is ignored.
when running out of quota on NFS (for example),
this can happen (without the patch):
output file(s) is/are truncated to 0 bytes and rsync reports success.
with the fix, this happens:
close /home/luser/.test.mp3.PwaG50: Disc quota exceeded
Those are really nice new options.
Second that! I think this is an awesome feature!
[EMAIL PROTECTED]:MM
This option allows you to specify at what time to stop rsync, in
[EMAIL PROTECTED]:minute numeric format (e.g. [EMAIL PROTECTED]:59).
Is there any reason to use a
On Tue, Apr 27, 2004 at 11:52:11AM -0600, Eric Whiting wrote:
... but here is some representative data:
Thanks for the confirming stats. Some questions/comments:
You didn't mention what command you ran, so I'm curious if the 18M jump
at the end was due to using --delete-after? (The way the
On Tue, Apr 27, 2004 at 09:24:32PM +0300, Sami Farin wrote:
return value of close() (receiver.c) is ignored.
Thanks! I've checked in a change based on your suggestion. I put the
--fsync option (w/o the -f shortcut) into the patches dir. (Such
changes are part of the initial work for the 2.6.2
On Tue, Apr 27, 2004 at 05:15:25AM -0500, John Van Essen wrote:
There was a change to rwrite() that seems to be preventing the error
logging.
Yes, you're right -- 2.6.0 changed this to make more errors go to the
user and fewer to the log file. Neither the old behavior nor the new is
really the
Wayne Davison wrote:
On Tue, Apr 27, 2004 at 11:52:11AM -0600, Eric Whiting wrote:
... but here is some representative data:
Thanks for the confirming stats. Some questions/comments:
You didn't mention what command you ran, so I'm curious if the 18M jump
at the end was due to using
Just built 2.6.1 and started testing it. Nice job guys. I especially love
the --progress and hardlink tweaks.
Quite often, while I have systems backing up out of cron, I'd love to be
able to see the --progress. Unfortunately, it's just not practical to
crank up the verbosity like that on a
Hi,
I have written a 'smallish' patch to implement the --inplace option
as discussed on this mailing list at various points in the past. It
makes a small modification to the sender algorithm so that it won't ask
the receiver to relocate blocks from earlier in the file when running
with the
Hi,
Results of a simple performance test on cygwin :
333 files, 30 MB, flat directory, 3 test runs after ramp-up,
Client : cygwin 1.5.9/ssh 3.8p on XP
Server : cygwin 1.5.9/ssh 3.8p on windows 2000 Server (VMWARE)
2.6.0 client to 2.6.0 server : 1
I knew that keep_partial didn't make sense with inplace, but hadn't
spent much time understanding that section of the code (took me long
enough to get my head around sender, receiver and match), so I made what
looked like the right change at the time. ;-)
Cheers,
Mark.
Wayne Davison wrote:
On
What about returning progress status when rsync receives a SIGUSR2?
It looks like there is code to return some sort of status when SIGUSR1
is sent. Is this accurate?
-John
On Tue, Apr 27, 2004 at 02:54:43PM -0700, Chuck Wolber wrote:
Just built 2.6.1 and started testing it. Nice job guys. I
I am using rsync version 2.3.2 on Sun (SunOS 5.8).
And I encountered the following problem that I hope the
guru of rsync on this list can shed light on.
The configuration is depicted as follows:
rsync
Sun data file - NFS file server (nfs)
|
Date: Tue Apr 27 19:59:37 2004
Author: wayned
Update of /data/cvs/rsync
In directory dp.samba.org:/tmp/cvs-serv7642
Modified Files:
util.c
Log Message:
In copy_file(), check len 0 before checking the close() return values.
Revisions:
util.c 1.140 = 1.141
Date: Tue Apr 27 23:40:17 2004
Author: wayned
Update of /data/cvs/rsync/patches
In directory dp.samba.org:/tmp/cvs-serv23445/patches
Added Files:
inplace.diff
Log Message:
Patch from Mark Curtis.
Revisions:
inplace.diffNONE = 1.1
26 matches
Mail list logo
