[Owncloud] Syncing and Time Synchronization

[Klaas Freitag]

On 18.07.2012 15:40, Bart Visscher wrote:
Hi,

>>> On Wed, Jul 18, 2012 at 10:31:13AM +0200, Klaas Freitag wrote:
>>>> For that, the best would be if the ownCloud WebDAV server would
>>>> provide another WebDAV property that returns the md5-sum of the file
>>>> or file list. That probably means that the md5 sum needs to be
>>>> calculated on every file change on the server and be stored in the
>>>> fs cache.
>>>
>>> I think you could use the etag for that, this is a standard property in
>>> WebDAV.
>> AFAIU Etags could help us here if the PUT of a new file to the
>> server would have an ETag in the response which could be stored on
>> the client. On subsequent sync runs, the Etag could be checked to
>> see if it has changed. Yet, currently I can neither see an etag in
>> the PUT response nor in a GET. That is probably because the getETag
>> implementation in lib/connector/sabre/file.php returns null. So that
>> would still have to be implemented.
>
> Yes, but this shouldn't be that much work.
Nice idea, but does not work ;-( . Currently the client gets file 
information directory wise, not by issuing an request for every file. 
Since etag work as HTTP header, that does not work here.

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.

BTW - if the client uploads new files via PUT, it probably can either 
send the MD5 with up or do an PROPPATCH after the upload. So no need for 
the server to calculate, only for the ones that do not come via the client.

regards,
Klaas

>
>>
>>> For transfering big files, i have looked at the librsync
>>> protocol/way. This uses a rolling checksum and a strong hash. The hash
>>> is md4 which is implemented by php. The rolling checksum is not
>>> implemented by php, I made a version in php, but this proved to be
>>> slow (1 second/MB on a fast machine). There is a PECL extension, but i
>>> think that as owncloud we should also have an alternative.
>> Yes, but that is another problem, right?
>
> Yes, was a bit sidelined by an other mail in this thread.
>
>>>
>>>
>>>>
>>>> Is that doable? Who can help with that?
>>>
>>> I we use the etag property we should calculate this when it is needed,
>>> not when the file changes. File can change multiple times in between
>>> etag requests.
>> Well, calculating an MD5 at least takes some time, so it would be
>> better to get that out of the DB rather than calculating it on
>> request.
>
> I wasn't quite clean, but this was in response to calculating the md5 on
> file changes. The flow i was thinking about is: etag needed ->  check db
> ->  not found: calculate and store ->  return etag.
>
> Bart
>
>>
>> regards,
>>
>> Klaas
>> _______________________________________________
>> Owncloud mailing list
>> Owncloud at kde.org
>> https://mail.kde.org/mailman/listinfo/owncloud