"state timesize" not working as expected
thorsten at thorstenkampe.de
Mon Oct 19 09:05:56 EDT 2009
* (19-Oct-09 14:55 +0200), Joe Orton
> On Sat, Oct 17, 2009 at 06:18:22PM +0200, Thorsten Kampe wrote:
>> While in my current environment both push and pull would be possible
>> as there is a direct connection between the hosts, I'd rather pull the
>> changes than push. This works fine for size and checksum changes -
>> just not for modification time changes.
> In timesize mode, sitecopy will store the mtime and size of the local
> file as the "stored state" for each file. At each update run, the
> current local state is compared against the stored state to determine
> whether or not a file has changed.
> When you do a --fetch in timesize mode, sitecopy will disregard all of
> the mtimes of the remote files, because these cannot be used to
> determine whether the local files are different to the remote files.
> The mtime of the file on the server will always normally be different to
> the local mtime - it will be the time at which the update has performed.
Hm, I don't fully understand that. Does that mean that "sitecopy in
pull mode" will not work with "timesize" because this is a design
>> The reason for preferring pull to push is that pushing changes to the
>> destination would mean that a part of the filesystem would be writable
>> remotely which I don't want for security reasons.
> If you have shell access to the remote server then I'd strongly
> recommend you use rsync to synchronize the sites. This will be more
> efficient, more reliable, and much faster than sitecopy in almost all
Yeah, I tried that and it works fine. I switched back to sitecopy
because it uses the already existing infrastructure (lighttpd). I
could also switch to the usual push mode. That together with a strong
password and webdavs would be secure. Or just live with "state checksum".
More information about the sitecopy