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
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
