I will have to connect quite inexperienced computer users at a distance.
So I'm not in favour of rebuilding the client db with all risk of problems.
Using ETags is a good invention and I strongly advocate for having them
predictable and no need for intervention on the client machines.
On Sept. 23rd PVince81 suggested in issue 10975 to use the checksum
as an ETag.
Best regards,
Henk
----- Original Message -----
From: "Klaas Freitag" <[email protected]>
To: <[email protected]>
Sent: Thursday, September 25, 2014 6:24 PM
Subject: Re: [owncloud-user] client etag rescan by removing
.csync_journal.db
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
_______________________________________________
User mailing list
[email protected]
http://mailman.owncloud.org/mailman/listinfo/user
