The log looks perfectly normal, although something is modifying the Thumbs.db files on the pool part folder itself.
The log indicates that it's performing a hash check and subsequently the hash check passes, but it can't synchronize the file modification time across all file parts in order to avoid the hash check in the future.
there are 2 things that are odd about that:
- The hash check is only performed when the file modification times of 2 or more file parts (representing the same duplicated file) are different. Normally this can happen if some application accesses the the pool part directly. I suppose you can also take the pool part and connect it to a different system to get the same effect. So the fact that the hash check is running is a bit odd.
- Access denied on a Thumbs.db is a bit odd too.
The operation canceled is perfectly normal, that just means we had to abort balancing / duplication in order to yield access to something accessing that file on the pool, we'll come back to that file later.
As for duplication tag consistency, this is how it works in 1.X vs 2.X:
- Both 1.X and 2.X have code that runs at service start-up that performs a quick pass over all the duplication tags on the pool (the stream tags that hold the duplication count for each folder).
- In 1.X, if a duplication tag exists on some pool part, the check ensures that the tag also exists on all the other pool parts that have that same folder. This is to repair the case where you end up with a missing duplication tag on one or more pool parts. Normally this should not happen, but if it does (say you manually delete and recreate a particular folder directly on a pool part) it will repair the tags.
- In 2.X, I've fleshed out the system a bit more and have made it more comprehensive. In addition to the functionality described above, the repair system parses each tag and ensures that they all match. If there is a mismatch, duplication tag conflict resolution takes place. This resolution is complicated to describe because it involves tag inheritance, but suffice it to say it always prefers to resolve duplication tag conflicts in the safer direction.
A simple example would be 2 pool parts, one has a duplication count of x2 and another of x3, the tags would be repaired to say x3 on all the pool parts.
It sounds to me like he may be running into a duplication tag conflict. Or perhaps one duplication tag is somehow stuck and the file system refuses to clear it. In 2.X we would see this in the log, but 1.X will not detect this.
As a last resort, you can create a new folder, enable duplication on that new folder, copy the contents of the old folder in there and then delete the old folder.