On 9/2/07, Wayne Davison <[EMAIL PROTECTED]> committed:
> A slightly changed version of Matt's %C (checksum) logging patch.
Cool! However, I'm not sure you need the special check to change a
checksum that is genuinely all zeros to all ones. The risk of rsync
ignoring a read error because the che
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
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
On Sat, Jun 30, 2007 at 04:17:29PM -0400, Matt McCutchen wrote:
> First, setting the xattr hits the file's ctime.
Yeah, I realize that, and that's why none of the xattr values cache the
ctime. This does mean that this method isn't good for updating checksum
values on existing files (since a gener
Matt McCutchen wrote:
> Second, it is impossible to make xattr-based checksum caching
> foolproof against same-second modification. Suppose a file is written
> during second 5 and then rsync caches its checksum during second 8;
> now the file has mtime 5 and ctime 8. Sometime later, rsync notices
On 6/30/07, Wayne Davison <[EMAIL PROTECTED]> committed:
Added Files:
checksum-xattr.diff
Log Message:
A simple patch that lets rsync use cached checksum values stored in
each file's extended attributes. A perl script is provided to create
and update the values.
Wayne,
You should be a
On 3/2/07, Wayne Davison <[EMAIL PROTECTED]> wrote:
Make the auto-generated protect filters use the perishable flag so
that they don't stop a vanished directory from being removed.
1. I don't think the --backup rule should be perishable. If I delete
an entire directory from the source, I would
On 10/8/06, the CVS server wrote on behalf of Wayne Davison <[EMAIL PROTECTED]>:
Log Message:
Clarify the short description of --chmod.
(i.e., from "change destination permissions" to "change the
permissions of transferred files")
I'm not sure this clarification is an improvement. --chmod affe
On Thu, Jan 16, 2003 at 03:18:34PM -0600, Dave Dykstra wrote:
> On Thu, Jan 16, 2003 at 04:08:01PM -0500, Scott Mcdermott wrote:
> > Dave Dykstra on Thu 16/01 14:57 -0600:
> > > > > The patch from 2-1/2 years ago for changing copy-unsafe-links to
> > > > > follow unsafe links on the destination sid
On Thu, Jan 16, 2003 at 08:25:32PM -0600, Dave Dykstra wrote:
> It doesn't look to me like your new code looks at the last
> component of the path like the old one might have.
Right. I thought to myself as I was re-writing the function that that
wouldn't be possible (to end with ".."), but I coul
On Thu, Jan 16, 2003 at 04:08:01PM -0500, Scott Mcdermott wrote:
> Dave Dykstra on Thu 16/01 14:57 -0600:
> > > > The patch from 2-1/2 years ago for changing copy-unsafe-links to
> > > > follow unsafe links on the destination side also included
> > > > essentially this patch.
> > >
> > > just to b
Sorry, another mistake on my part -- I didn't realize the strtok side
effect. It doesn't look to me like your new code looks at the last
component of the path like the old one might have. It would probably
be a good idea to put tests ending in "/..", for example "foo/../.."
and "foo/..", into tes
On Thu, Jan 16, 2003 at 02:33:26PM -0600, Dave Dykstra wrote:
> I think you could get rid of the calls to strdup() and the new local
> variables and possibly do a couple casts inside the function instead.
You wouldn't want to carve up the const strings with strtok() (which
adds nulls to the string
Dave Dykstra on Thu 16/01 14:57 -0600:
> > > The patch from 2-1/2 years ago for changing copy-unsafe-links to
> > > follow unsafe links on the destination side also included
> > > essentially this patch.
> >
> > just to be clear, without using copy-unsafe-links, rsync still
> > copies absolute sym
On Thu, Jan 16, 2003 at 03:44:44PM -0500, Scott Mcdermott wrote:
> Dave Dykstra on Thu 16/01 14:33 -0600:
> > The patch from 2-1/2 years ago for changing copy-unsafe-links to follow
> > unsafe links on the destination side also included essentially this patch.
>
> just to be clear, without using c
Dave Dykstra on Thu 16/01 14:33 -0600:
> The patch from 2-1/2 years ago for changing copy-unsafe-links to follow
> unsafe links on the destination side also included essentially this patch.
just to be clear, without using copy-unsafe-links, rsync still copies
absolute symlinks which point out of t
to strdup() and the new local variables and possibly do a couple
casts inside the function instead.
- Dave
On Wed, Jan 15, 2003 at 12:49:44PM -0500, [EMAIL PROTECTED] wrote to rsync-cvs:
> Re: CVS update: rsync
>
> Date: Wed Jan 15 17:49:44 2003
> Author: wayned
>
> U
On 14 Dec 2001, [EMAIL PROTECTED] wrote:
> Modified Files:
> options.c
> Log Message:
> When INET6 is not defined, meaning that IPv6 is not supported, need to
> initalize the global_opts.af_hint to AF_INET or systems such as Linux that
> have a native getaddrinfo() because they support IPv
On 14 Dec 2001, [EMAIL PROTECTED] wrote:
> open_socket_in was attempting to try all the protocols returned from
> getaddrinfo(), but only if a corresponding call to socket() returned one of
> three *NOSUPPORT errno codes. A Redhat 6.2 system was observed returning
> EINVAL instead so it never we
On 28 Nov 2001, Dave Dykstra <[EMAIL PROTECTED]> wrote:
> The HP compiler needs a -Ae to accept ANSI.
Sadly the compiler on this machine reports:
configure:5002: cc -c -Ae -DHAVE_CONFIG_H conftest.c >&5
(Bundled) cc: warning 480: The -A option is available only with the C/ANSI C product;
igno
On 8 Feb 2001, Martin Pool <[EMAIL PROTECTED]> wrote:
>
> Date: Thursday February 8, 2001 @ 14:28
> Author: mbp
>
> Update of /data/cvs/rsync
> In directory samba:/tmp/cvs-serv14515
>
> Modified Files:
> options.c
> Log Message:
> Document shortcoming of "unrecognised option" mess
28 matches
Mail list logo
