On 25.09.2014 17:47, Markus Goetz wrote:
On 25/09/14 17:26, Jakub Moscicki wrote:
This is to let you know what we do certain migration situations when
the etags on the server are lost or scrambled. I would like to know if
anyone is having a similar practice or if client developers see any
problem with that (and are aware that we use this as a feature of the
system).
I don't see a problem. Removing the client db (and only that, not the
server db!) must be secure. So if this does not work, it would be a
severe bug.
That said, I think the server storage backends should create more
predictable ETags.
For a normal filesystem backend, this could be something like a
hash(inode + filesystemid + size + mtime).
That way such situations (I heard of people uninstalling and
re-installing the oC server to upgrade) are better handled without any
intervention needed on the sync client machines.
Yes, but that would only pay off if the etag was the only datum on the
server which could not be reproduced from the file system. Or to phrase
it the other way round: It would be cool if the server also could
recalculate its entire file system cache in the database.
regards,
Klaas
_______________________________________________
User mailing list
[email protected]
http://mailman.owncloud.org/mailman/listinfo/user
