On Wed, Apr 07, 2004 at 11:24:46PM -0400, Jim Salter wrote:
So, just to clarify - this is a bug that needs fixing only on the
server side, not the client side, correct?
Yes, that's correct.
..wayne..
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before
I'm not on the list but I just wanted to throw my positive feedback out
there. I've been using rsync to backup work that I generate within a
lab to an offsite system. If I lost this data ...
So great.
In standard community fashion, though, I want to throw an idea out
there. It would be nice
Hi,
On 2004/04/05 07:21, Donovan Baarda wrote:
[snip]
there are four ways crafted blocks can be use;
1) two crafted blocks in the original file
2) two crafted blocks in the target file
3) a crafted pair of target and original files with matching
block(s)
4) a block in the target
G'day,
From: Eran Tromer [EMAIL PROTECTED]
[...]
librsync needs a whole file checksum. Without it, it silently fails for
case 1), 3), and 4).
librsync could benefit from a random checksum_seed. It would need to be
included in the signature. Without it librsync is vulnerable to cases 1)
On 2004/04/08 08:50, Donovan Baarda wrote:
In some cases you might prefer to actually store an signed signature
using something like GPG.
I think librsync should act as a black box that guarantees file
integrity (which, apparently, requires a whole file checksum). If
someone wants to add
G'day again,
From: Eran Tromer [EMAIL PROTECTED]
[...]
if the
checksum_seed is based on something like the whole file md4sum, it
becomes repeatable, but unpredictable. You can't manipulate individual
blocks without it affecting every other blocksum, but the signature for
the same file
Ahoy,
On 2004/04/08 14:16, Donovan Baarda wrote:
Nice indeed, but the cost is enormous: you'll have to read the file
twice. When syncing a mostly-unchanged file that's larger than the disk
cache, that means doubling the runtime (and disk load) on the receiver's
side. Also, it means 'rdiff
Use # find on the remote system and list | rm files that meet
your date criteria ?
I'm not on the list but I just wanted to throw my positive feedback out
there. I've been using rsync to backup work that I generate within a
lab to an offsite system. If I lost this data ...
So great.
On Thu, Apr 08, 2004 at 03:50:48PM +1000, Donovan Baarda wrote:
I think I've just realised what you were getting at; if the
checksum_seed is based on something like the whole file md4sum, it
becomes repeatable, but unpredictable.
Not so. Copy the file once, and you'd get all the data you'd
Thanks Wayne!
reading of the files on the source machine. However, you can include
all the source filesystems as args in a single copy command and it will
enforce the single-filesystem (inode-based) restriction separately for
each arg you specify:
rsync -avxR -e ssh --numeric-ids
OK. Didn't see anything about this in the archives, other than an old post
from 2000 about a similar problem, so here goes. Feel free to contact me if
I can provide anything else useful.
Problem:
Major numbers on 64bit Solaris are being dropped, and created as 0 on
recieving end.
On Thu, Apr 08, 2004 at 01:43:18PM -0700, Williams, Tom wrote:
Major numbers on 64bit Solaris are being dropped, and created as 0 on
recieving end. 32bit version works perfectly.
Looks like the code is masking a 64-bit number with a 32-bit mask
(ouch)! Try the attached patch and let me know
On Thu, Apr 08, 2004 at 01:43:18PM -0700, Williams, Tom wrote:
rsync version 2.6.0 protocol version 27
I just noticed that you aren't talking about the 2.6.1 pre-release, so
that patch I just sent won't do you any good unless you first download
that:
On Thu, Apr 08, 2004 at 02:33:29PM -0700, Wayne Davison wrote:
If you could retry things using the pre-release + patch, I'd
appreciate it!
Note that my patch won't fix the problem because rsync only transmits
the lower 32 bits of the rdev value. To fix this will require a
protocol change.
We seem to working from wildly different revs of flist.c :) Mine is the
stock file from the 2.6.0 source. I don't even find an occurance of 0xFF in
there, so your patch wouldn't apply, even by hand -- the code is just too
different.
I think I understand what you were attempting to accomplish
Excellent! In the meantime, the 32bit + -D_FILE_OFFSET_BITS=64 works
brilliantly, so I'll wait for a release. This is meant to run on prod
boxes, so I need to use a release if possible, so noone asks funny questions
about beta software, etc.
You know how it is.
I just have to remember to
I wrote a tool to get around a similar problem. In my case, I had to bail
on rsync altogether... the hardware was just too unreliable and limited in
resources.
I've BCCd the current custodian of that tool, who was at least at one time
a member of this list. If my old company has no objection
Dear Mr.Tim,
Options used in rsync command in our system:
rsync --verbose --recursive --update --delete
--group --owner --times --perm
Eventhough i am using -owner option while synching to the mate system.
The owner ship from the System A is not restored in the System B.
( System B is
Date: Thu Apr 8 06:38:46 2004
Author: wayned
Update of /data/cvs/rsync/patches
In directory dp.samba.org:/tmp/cvs-serv8981
Added Files:
ODBC-dblog.diff
Log Message:
Daemon logging to a database.
Revisions:
ODBC-dblog.diff NONE = 1.1
Date: Thu Apr 8 23:05:36 2004
Author: wayned
Update of /data/cvs/rsync
In directory dp.samba.org:/tmp/cvs-serv7355
Modified Files:
flist.c
Log Message:
Fixed a bug in the sending of rdev when the high-bits match.
Revisions:
flist.c 1.207 = 1.208
Date: Fri Apr 9 00:33:34 2004
Author: wayned
Update of /data/cvs/rsync
In directory dp.samba.org:/tmp/cvs-serv22506
Modified Files:
tls.c
Log Message:
If we're listing a device, out the major and minor device numbers.
Revisions:
tls.c 1.15 = 1.16
Date: Fri Apr 9 00:36:45 2004
Author: wayned
Update of /data/cvs/rsync/testsuite
In directory dp.samba.org:/tmp/cvs-serv23705/testsuite
Modified Files:
devices.test
Log Message:
Added a couple extra character devices to be copied.
Revisions:
devices.test1.6 = 1.7
22 matches
Mail list logo
