On 7/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I understand that it's a fairly low probability, and
depends on some questionable configurations, but rsync is well-known
to be both reliable and deterministic. I'd hate for something like
this to start chipping away at that reputation, eve
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
On 7/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Unreliable. If you sync up at the beginning of a run, and then the
remote system executes a large clock step (e.g., because it's not
running NTP or it's misconfigured, or it is but NTP has bailed due to
excessive drift from hardware issues
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
On 7/2/07, Wayne Davison <[EMAIL PROTECTED]> wrote:
On Mon, Jul 02, 2007 at 08:43:39AM -0400, Matt McCutchen wrote:
> What do you mean? There's no way to fix the example I gave with
> xattrs
Not so. I went on to explain how that is possible in my prior email
(i.e. avoiding caching a checksum o
On Mon, Jul 02, 2007 at 10:28:25AM -0700, Wayne Davison wrote:
> It is if you're doing one check to see if a file is being updated (e.g.
> stat() followed by time() to compute "now"). If time rolls over between
> the two calls, you may have just missed that the mtime would now match
> if you did a
On Mon, Jul 02, 2007 at 08:43:39AM -0400, Matt McCutchen wrote:
> What do you mean? There's no way to fix the example I gave with
> xattrs
Not so. I went on to explain how that is possible in my prior email
(i.e. avoiding caching a checksum on a "now" mtime file is all that is
needed).
> That's
Matt McCutchen wrote:
On 7/1/07, reno <[EMAIL PROTECTED]> wrote:
I'm experiencing various output bugs using --out-format with %f in
rsync 2.6.9
You seem to expect that %f will always give you an absolute path, but
that's not what it is designed to do. In the rsyncd.conf man page,
"long form o
On 7/1/07, Wayne Davison <[EMAIL PROTECTED]> wrote:
[...] It is still useful for allowing a server to cache the
checksum values without requiring any extra files. As long as it is
used on files that aren't being actively updated, it works great.
OK, that's reasonable.
> Second, it is imposs
https://bugzilla.samba.org/show_bug.cgi?id=4757
--- Comment #2 from [EMAIL PROTECTED] 2007-07-02 07:14 CST ---
Bummer. Please document that in the rsyncd.conf man page.
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--- You are receiving this mail bec
11 matches
Mail list logo
