[Yes, I am reviving a thread from 27 months ago. Why? Because
I gave up on the problem way back then and didn't move the vault.
Now that I'm really trying to do this, it still doesn't make any
sense... :) Matt CC'ed directly since he was the primary respondent
and I have no idea if such an old t
> Date: Sun, 25 Jan 2009 01:02:15 -0500
> From: Matt McCutchen
> I regret the slow response. I was interested in your problem, but I
> knew it would take me a while to respond thoughtfully, so I put the
> message aside and didn't get back to it until now. I hope this is stil
I've got a problem for which the combination of -R and --link-dest
doesn't seem to be quite enough---and I may have discovered a few
small bugs as well; test cases are below.
[And if someone has a scheme for doing this that doesn't involve rsync
at all, but works okay, I'm all ears as well---I'm n
> Date: Wed, 5 Dec 2007 23:21:27 -0500
> From: "Doug Lochart" <[EMAIL PROTECTED]>
> Each module needs to be protected from the others so if a user logs in
with
> their credentials they should not have access to any other module. It
> would take a user knowing the name of ano
Date: Tue, 06 Nov 2007 23:18:08 -0500
From: Matt McCutchen <[EMAIL PROTECTED]>
On Tue, 2007-11-06 at 22:22 -0500, [EMAIL PROTECTED] wrote:
> I worry about those trying to write things that parse rsync's output;
> if -n changes the output format, such things will have to be test
> Date: Mon, 05 Nov 2007 13:17:32 -0500
> From: Matt McCutchen <[EMAIL PROTECTED]>
> I think rsync should omit the speedup on a dry run. The attached patch
> makes it do so.
I worry about those trying to write things that parse rsync's output;
if -n changes the output format, suc
Date: Wed, 11 Jul 2007 01:26:18 -0400
From: "George Georgalis" <[EMAIL PROTECTED]>
the program is http://www.ka9q.net/code/dupmerge/
there are 200 lines of well commented C; however
there may be a bug which allocates too much memory
(one block per file); so my application r
Date: Mon, 2 Jul 2007 21:18:57 -0400
From: "Matt McCutchen" <[EMAIL PROTECTED]>
The technique Wayne and I are discussing assumes only that the clock
on *each side* never steps backwards.
Um, and note, btw, that the pathological FSB-spread-spectrum/NTP
interaction I mentioned in my
Date: Mon, 2 Jul 2007 21:18:57 -0400
From: "Matt McCutchen" <[EMAIL PROTECTED]>
The technique Wayne and I are discussing assumes only that the clock
on *each side* never steps backwards. It compares the current mtime
and ctime on each side to the previous mtime and ctime on th
Date: Mon, 2 Jul 2007 08:43:39 -0400
From: "Matt McCutchen" <[EMAIL PROTECTED]>
> *Note that "now" for a particular disk may not be the same as time() if
> the disk is remote, so network filesystems can be rather complicated.
That's easy to fix: get your "now" by touching a fi
Date: Fri, 16 Mar 2007 02:30:33 -0700 (PDT)
From: syncro <[EMAIL PROTECTED]>
Thanks alot! That's what I wanted to hear ;)
We want to have an always-up-to-date-copy thus rsync every minute and not
just at night. However my preventive measure will be a forbiddance of
sharing
Date: Mon, 12 Jun 2006 18:01:34 -0400
From: Matt McCutchen <[EMAIL PROTECTED]>
On Mon, 2006-06-12 at 17:51 -0400, [EMAIL PROTECTED] wrote:
> The right solution is probably to run an encrypted filesystem on the
> machine that holds the backups, and of course to use ssh getting t
Date: Mon, 12 Jun 2006 14:18:00 -0400
From: Matt McCutchen <[EMAIL PROTECTED]>
On Mon, 2006-06-12 at 10:58 -0700, Chuck Wolber wrote:
> On Mon, 12 Jun 2006, Brad Farrell wrote:
>
> > Is there a way with rsync to encrypt data at the source before
> > transmitting? Not
Date: Wed, 8 Mar 2006 17:15:36 -0800
From: Wayne Davison <[EMAIL PROTECTED]>
On Wed, Mar 08, 2006 at 01:48:37PM -0800, Jonathan Chen wrote:
> 2006/03/08 11:25:12 [16976] malformed address localhost.localdomain
That can't be 2.6.6 because 2.6.6 doesn't have an error message of
14 matches
Mail list logo
