> > I understand the concept and indeed its good. It's very near to what I want > to implement, with the only difference that instead of the hash sums, I'd > like to use the mtimes, as csync does. Why do we think thats a benefit: Well, > based on the mtimes its decideable which version is newer. Moreover, the > mtime is already a natural meta data in each file system, so we do not have > to add something new. That given, csync runs without server support by now. > > What is missing is the propagation of the mtimes from individual files and > directories to their parent directory. If we do that with the ownCloud server > support, I think we will have the same benefits that you described above. As > we have the data in a database server side we will be able to retrieve the > data fast.
Does this mean that if I run this on a machine with an incorrect date (in the future) I could potentially wipe out the entire server state? I think using the modification time is a flawed idea.. The way dropbox handles this is, imho the better way.. * Always assume that the server state is the current state. * Clients have a hash of the last known server-state * When clients pushes a new version of a file, they include the last known hash (much like If-Match:, but it wouldn't have to be enforced) * If the client attempts to do an update with an old hash, make a duplicate of the previous server state as a conflicted copy. > >> >> Note that there is a related RFC - http://tools.ietf.org/html/rfc6578 - >> however I'm not confident that the approach outlined there is quite right. > Do you know if its implemented in a WebDAV server already? I'm currently working on a plugin for this :) Evert _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
