Hello Jan and Phil,

On Wed, Oct 27, 2010 at 02:25:21PM -0400, Jan Harkes wrote:
> It isn't as simple as just adding hashes, there is an interaction with
> potentially pending write operations in the modification log that are
> removed when we reintegrate while the file is open for writing. So there
> has to be some care taken to weave this correctly around CML store
> optimization logic to avoid losing data.

Hope it is not all too complicated and risky.

I guess that the alternative - handling of the extra "modified" flag -
would imply similar complications anyway?

> But having a valid hash for any not-currently-owrite file would have
> several other benefits, such as improving reliability and performance of

I would prefer a more general solution of the two being considered.
Hashes are more general than a "modified" flag and give some extra
advantages so it would be worth adding this functionality despite
the performance hit.

Presumably it is possible to trade hash calculations against extra
reintegrations per client, say by always returning "changed" instead
of a hash calculation, with the resulting behaviour corresponding to
today's one.

If we want to avoid the performance hit on platforms where we track
writes (e.g. Windows) then Phil's proposal fits better - but I would
happily accept the hash calculations' expenses.

Regards,
Rune