times difference causes write

David Bolen db3l at fitlinxx.com
Wed Nov 14 09:00:37 EST 2001

Don Mahurin [dmahurin at berkeley.innomedia.com] writes:

> My second problem is that the flash is of limited size, so I need
> some sort of patch rsync that does not keep the old file before
> writing the new one.  My patch now just unlinks the file ahead, and
> implies -W.

Sounds reasonable as long as you force the -W.

> So my wish was that a time discrepancy would lead to a checksum, where the
> files would match.
> This is not the case, however, as you say.

At least not with -W.

In most cases, the time discrepancy would then cause rsync to try to
synchronize the file, and during its protocol processing it would
determine that it didn't need to send anything, thus the only end
result would be adjusting the remote timestamp to match the source.
But this requires access to the original source file, so your prior
patch (and forcing -W) defeats this as a side effect.

> So for now, I must use -c.  It's slow, but I know that I get the minimum
> number of writes.

It definitely sounds like the best match for you.  Although -c tends
to be used more for cases where files may differ although they appear
the same (timestamp/size) than vice versa, it will serve that purpose
as well at the expense of some additional I/O and computation.

Presumably you could modify your patch so that -c (or some new option)
only invoked the checksum if the timestamp differed, since I don't
think there's any suitable equivalent currently in rsync.

-- David

 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \

More information about the rsync mailing list