"state timesize" not working as expected

Thorsten Kampe 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
limitation?

>> 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 
> cases.

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".

Thorsten




More information about the sitecopy mailing list