> I am curious why mtime is not sufficient. My thoughts would be to > determine a time difference before the sync. Then use that difference > when determining which files to transfer and apply the time difference > after writing a file to the client or server as needed.
Two reasons why using time is a bad idea 1. It's not accurate. Even if there's a difference of seconds, it could throw a wrench in the system; if it's hours (not uncommon for end-users), mass overwriting may ensue ;) 2. The latest (in time) does not always imply that it's the 'final version'. One look at an active github repository, and you notice that sequential changes in files, are not always in sequential in time. You can argue that #2 is a potential edge case, and #1 is something you can solve with workarounds and fuzzy logic. However, synchronization is a 'solved problem' and there are very robust ways to do this. If you'd do it based on the modification time instead, you reinvent the wheel, but kind of in a bad way. Your wheel is made out of paper-maché, and breaks if you go too fast with it. Evert > > -Jono > > On Wed, Jul 18, 2012 at 12:23 PM, Evert Pot <[email protected]> wrote: >> On Jul 18, 2012, at 4:57 PM, Klaas Freitag wrote: >> >>> On 18.07.2012 16:30, Evert Pot wrote: >>> Hi Evert, >>> >>>>> We instead have to implement it as Custom webdav property which the >>>>> client can query via PROPFIND, and gets the MD5 sum for every file in >>>>> return. >>>> >>>> http://tools.ietf.org/html/rfc4918#section-15.6 >>> Ah ok, that teaches us that we can get the etag as a property too. Did not >>> know that, thanks :-) >>>> >>>> >>>> Related to the sync discussion; don't ignore this rfc: >>>> >>>> http://tools.ietf.org/html/rfc6578 >>>> >>>> It's easily superior to all the approaches discussed here in the last >>>> little while. >>> Oh yes. Is it implemented with Sabre somewhere? Sounds like the overall >>> target we should strive for. >> >> Not yet, it's planned and there's a branch: >> https://github.com/evert/SabreDAV/tree/webdav-sync >> >> But it's a bit hard to say when it's ready. >> >> If you want to support it in owncloud in the future, you should at least >> have support for: >> >> * A concept of sync-tokens. These are similar to ETags, but apply to the >> contents of an entire collection. >> * Changelogs, containing deletes and modifications of files. also for an >> entire collection. >> >> This should be a solid basis for whatever sync approach you take :) >> Evert >> _______________________________________________ >> Owncloud mailing list >> [email protected] >> https://mail.kde.org/mailman/listinfo/owncloud > _______________________________________________ > Owncloud mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/owncloud _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
