Dave, the HashQueue behaviour is correct... suppose you create a file A and rename the file to B.
HQ gets queued to hash A, but it's not there anymore! it should quit? (B will never be hashed) What it does is to send HQ_HASH_ERROR, so Sync will get that, will get the node_id, get the path (that will be B), and hash again the node (path B, now). But, what happens if the HQ_HASH_ERROR is processed before the FS_FILE_MOVE? A is sent to process again! Normally, just a couple of times, until the FS_FILE_MOVE is processed. In the case presented in this bug, we *do* have a bug, but it's not in HQ, it's in how the filesystem notifications are processed. See, we're failing to issue a FS_FILE_DELETED when you rename something valid to something ignored. So, as Sync never deletes the file, the HQ stucks in a loop. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/580855 Title: Ubuntu One sync daemon continuously hashing -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
