I have the following module defined in rsyncd.conf:
[updates]
list = no
hosts allow = foo
path = /ext/updates
exclude = incoming
>From host "foo", if I run:
$ rsync -arHvn --delete bar::foo /ext/updates
then the /ext/updates/*/incoming directory will be deleted. However,
If I
rsync 2.5.2 on FreeBSD 4.4-STABLE.
my rsyncd.conf looks like this:
read only = yes
[test]
path = /tmp
I am starting rsync as root like this:
rsync --daemon
when I connect to the rsync server on the localhost I get this:
myhost# rsync localhost::
test
but when I connect, from the localhost,
I just tried running Splint across rsync. (Splint is the C-checking
lint tool previously called LCLint.)
In default mode it gives 2552 (!!) warnings for rsync alone, not
including zlib or popt. In -weak mode, it gives 390. Of course, the
vast majority will not be real errors, but from past exp
Thanks all who replied.
So to conclude: rsync does the delta stuff i need, but it writes the
destination file completly new instead of patching the deltas.
Unfortunatly i have a offline database where i need a tool which does a
simple compare of fixed size blocks and modifies only the changed
On Fri, 22 Feb 2002, Dave Dykstra wrote:
> > > At the same time, the server child process is doing a 262K read from another
> > > file over the same NFS connection and it takes the same 9 minutes and
> > > eventually suceeds. It only dies because the other server process had died
> > > and it ge
On 21 Feb 2002, Oliver Krause <[EMAIL PROTECTED]> wrote:
> Hi,
>
> after some searching i didn't came up with an answer so please excuse if this
> is a total newbie question.
>
> My problem:
> I have server A which has a big (>500G) database like file. On server B i
> want to have a copy of th
Martin Pool [[EMAIL PROTECTED]] writes:
> It could be an interesting project to try to build rsync under MSVC++.
> Presumably it can handle large files. I don't think there's anything
> impossible in principle about it.
Not in principle, but unless you're also going to handle the same fork
emul
On 21 Feb 2002, Joseph Annino <[EMAIL PROTECTED]> wrote:
> This is cool. You can't really tell that this is what is going on from
> reading the man page.
I'd really like to improve the state of documentation for rsync. The
man page has grown organically and is not really appropriate for the
cur
On 21 Feb 2002, David Bolen <[EMAIL PROTECTED]> wrote:
> I'm pretty sure Cygwin itself has a 2GB (32-bit) limitation for files.
> Large file (64-bit) support for Cygwin has come up in various ways
> repeatedly on the Cygwin mailing list but it generally ends up at the point
> where if someone is
Dear Sir,
My name is ChenHua, and I'm writing on behalf of the
China-Lutong mechanical company. Located in the south east
of China, we specialize in hydraulic heads for the VE
distributor pump.
We can supply standard, good quality units at a very
competitive price. The following type
On Fri, Feb 22, 2002 at 12:10:52PM -0500, David Birnbaum wrote:
> On Fri, 22 Feb 2002, Dave Dykstra wrote:
>
> > [adding the mailing list to the Cc after David sent me trusses and other
> > info about his hang. I have trimmed down the tracing info to the relevant
> > pieces.]
> >
> > On Tue, Feb
On Thu, Feb 21, 2002 at 11:20:21PM -0800, Jos Backus wrote:
> On Thu, Feb 21, 2002 at 05:49:03PM -0600, Albert Chin wrote:
> > If I case &s->count to (unsigned int *), then it compiles.
>
> How about casting to size_t * (since s->count has type size_t)?
We can either cast &s->count to (unsigned
On Fri, Feb 22, 2002 at 08:48:03AM +0100, ASendrowski wrote:
> my situation:
> i have a production-server with Solaris 7 and a 200 GB RAID attached.
> the server runs without troubles for month.
>
> I build an backup-server with same configuration. i installed
> rsync-2.3.1-binaries on both mac
On Fri, 22 Feb 2002, Dave Dykstra wrote:
> [adding the mailing list to the Cc after David sent me trusses and other
> info about his hang. I have trimmed down the tracing info to the relevant
> pieces.]
>
> On Tue, Feb 19, 2002 at 11:51:27PM -0500, David Birnbaum wrote:
> > I wasn't able to get
It uses a "rolling" checksum, so that it can actually find byte-level
changes, insertions, deletions. There's a block size for how big a chunk
to start with, but then it works within those to figure out where to make
the changes. It's hyper-efficient. The thing about transferring whole
file
[adding the mailing list to the Cc after David sent me trusses and other
info about his hang. I have trimmed down the tracing info to the relevant
pieces.]
On Tue, Feb 19, 2002 at 11:51:27PM -0500, David Birnbaum wrote:
> I wasn't able to get a netstat this time. However, I should be able to
>
On Fri, Feb 22, 2002 at 08:48:03AM +0100, ASendrowski wrote:
> hi,
>
> i have trouble with rsync on solaris.
>
> my situation:
> i have a production-server with Solaris 7 and a 200 GB RAID attached.
> the server runs without troubles for month.
>
> I build an backup-server with same configurat
Keep in mind that rsync always generates a complete copy of the file on the
receiver side, it doesn't actually modify the file; it takes chunks out of
the original file and combines them with the changed chunks sent from the
receiver to make a new file, and when it's all done it deletes the old
on
18 matches
Mail list logo
