rsync commandline:
/usr/bin/rsync -e /usr/bin/ssh --archive --compress --sparse
--verbose --stats --delete --numeric-ids --partial --relative
--one-file-system target.host:/ /destination/path/
target rsync version: 2.6.3
destination rsync version: 2.6.2
The server we're trying to synchron
WD == Wayne Davison <[EMAIL PROTECTED]>
WD> The most useful thing would be for someone to get a core dump of the
WD> crash, list the backtrace, and discover if this is a bug in the
WD> libraries. If (as I suspect) it is, a bug report to the affected
WD> library's author is in order.
Let me know i
On Tue, Mar 01, 2005 at 03:53:45PM -0800, Josh Smith wrote:
> The problem when away if I turned off chroot, or if I put a copy of
> libnss_ldap.so.2 into ${path}/lib/libnss_ldap.so.2.
Some folks have been reporting that an rsync daemon running on FC 2 (and
now FC 3) with chroot enabled dies when t
https://bugzilla.samba.org/show_bug.cgi?id=2403
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.samba.org/show_bug.cgi?id=2403
Summary: ssh port setting
Product: rsync
Version: 2.6.4
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P3
Component: core
A
On 2005-03-01 16:26:56 -0500, Andrew Gideon wrote:
> So is there a way around this? I was thinking about having the client run a
> program on the backup server which causes the usual server-initiated backup
> to occur. But how would this work if the laptop is behind a NAT device?
Use ssh (with f
[* I'm not on the mailing list, so please copy me on any replies; thanks. *]
I was running an anonymous rsync server with chroot (i.e. not overriding
the default) on a Fedora Core 2 system using flat files for
authentication, which I recently upgraded to Fedora Core 3 using LDAP for
authentication
This is less a question about rsync and more about how rsync can be used as
a backup solution in a particular case. If one of the tools built over
rsync for this purpose solves this, I'm eager to hear how. Otherwise,
suggestions are welcome.
Server-initiated backups are easy. The rsync process
On Tue 01 Mar 2005, Wayne Davison wrote:
> On Tue, Mar 01, 2005 at 09:34:02AM -0800, Wayne Davison wrote:
> > The period is part of what is output (to make them all 4 characters
> > wide).
>
> The other string choice I considered was using "delt" instead of "del.".
> Maybe that would be better?
N
On Tue, Mar 01, 2005 at 09:34:02AM -0800, Wayne Davison wrote:
> The period is part of what is output (to make them all 4 characters
> wide).
The other string choice I considered was using "delt" instead of "del.".
Maybe that would be better?
..wayne..
--
To unsubscribe or change options: https:
On Tue, Mar 01, 2005 at 04:44:07PM +0100, Paul Slootman wrote:
> - the old -c, --checksum line hasn't been removed.
> - there's a -C without enclosing \fB and \fP
Thanks -- I've checked in fixes for these.
> - you replaced behaviour with behavior. I prefer the former (having
> been to a
Shachar-
True enough - with one
additional thought - if the block size is
set to be the square root of the file size,
then the load factor on the hash table becomes
dynamic in and of itself (bigger block size
= less master table entries = fewer hash
collisions).
In the case of relative
On Mon 28 Feb 2005, Wayne Davison wrote:
> I've released rsync 2.6.4pre2. It was a little sooner than expected,
A couple of things in rsync.1:
- the old -c, --checksum line hasn't been removed.
- there's a -C without enclosing \fB and \fP
In rsyncd.conf.1:
- you replaced behaviour wit
Michael Best wrote:
I ask because a client had a broken filesystem that occasionally has 2T+
files on it (broken filesystem, so they weren't actually that big) but
we happily ran up a huge b/w bill with rsync.
For this specific example you could probably wildcard match the files with a
--exclude
14 matches
Mail list logo
