© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
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.