Re: checksum-xattr.diff [CVS update: rsync/patches]

2007-07-02 Thread Matt McCutchen
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

Re: checksum-xattr.diff [CVS update: rsync/patches]

2007-07-02 Thread Wayne Davison
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

Re: checksum-xattr.diff [CVS update: rsync/patches]

2007-07-02 Thread Wayne Davison
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

Re: checksum-xattr.diff [CVS update: rsync/patches]

2007-07-02 Thread Matt McCutchen
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 on a

Re: checksum-xattr.diff [CVS update: rsync/patches]

2007-07-02 Thread Matt McCutchen
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

Re: checksum-xattr.diff [CVS update: rsync/patches]

2007-07-02 Thread Matt McCutchen
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, even

Re: checksum-xattr.diff [CVS update: rsync/patches]

2007-07-01 Thread Wayne Davison
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

Re: checksum-xattr.diff [CVS update: rsync/patches]

2007-06-30 Thread Matt McCutchen
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

Re: checksum-xattr.diff [CVS update: rsync/patches]

2007-06-30 Thread Jamie Lokier
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