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 destinat
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 t
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 compil
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 wit
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. I'
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:
http://rsync.samba.org/ftp/rsync/previ
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
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. 32bit
Answered my own question... here's what I came up with in case anyone else
wants the answer:
FILESYSTEMS=`ssh -q [EMAIL PROTECTED] df -l|awk '/\// {print $NF}'|tr '\n' ''`
rsync -av -e 'ssh -q' --one-file-system --numeric-ids --relative \
--delete [EMAIL PROTECTED]:"${FILESYSTEMS}" /backups/
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
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
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.
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
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
> > th
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 authe
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
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
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 i
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 po
19 matches
Mail list logo
