[Owncloud] Syncing and Time Synchronization

[Evert Pot]

On Jul 19, 2012, at 1:09 PM, Jono wrote:

> I have to be honest, I dont understand either of these cases.
> 
> 1. "mass overwriting"? Are you referring to modifying many timestamps?

What happens if I move a local directory to a new location? What if some application on a users' system touches files, for whatever reason?
I've seen people put git checkouts *in* their dropbox. While this is not the smartest thing to do, people do it anyway.

I'm pretty certain when you switch branches in git, or do a pull.. most files in a repository will be 'touched'; which is bad!

> 2. Directory structures do not have non sequential branches like git
> repos. Maybe you are referring to something else?
> 
> If this is a 'solved problem', can you direct me to some writtings on
> the subject. For some reason all these checksums are not sitting well
> with me. Sounds expensive any way you do it.

> I will say I do like that RFC. It gives me another idea, though I am
> not sure if it would apply to WebDav. It does not use timestamps or
> checksumsaccross the network, so maybe it does not make sense, but
> here it is:
> 
> In the client and server database we maintain a sync-token for each
> file. The token can just be a random generated value that will be
> regenerated on the server every time the file is in a new state. When
> the server and client tokens differ it means the version of the file
> on the server is the latest. If the token on the server and client
> match, the files match.

exactly.

> 
> We maintain timestamps in the client database. So when a file is
> updated on the client side, we can check its timestamp against the
> client database and see if it needs to be sent to the server.

Yea a timestamp makes sense on the client, also an md5. But *only* to see if the local copy changed from a previous state.

> 
> I know we are steering away from using timestamps over the network,
> but is it ok to use it locally? I can see problems with this when the
> user decides to change their system clock, but maybe that is a
> different issue.

I'd personally use timestamps and changes in filesize just as cheap way to figure out a file *may* have changed. If the timestamp is different (but not the size), I would still do md4/md5 checks to make sure there was an actual change.

Evert