Comment 10 for bug 551095

I have the full logs of Rick, you can find them at chinstrap:/home/rmcbride/20100401logs.tar.gz

Relevant part is:

2010-03-31 19:45:17,958 - ubuntuone.SyncDaemon.Main - NOTE - ---- MARK (state: <State: 'QUEUE_MANAGER' (queues WORKING_
ON_BOTH connection 'With User With Network')>; queues: metadata: 31498; content: 923; hash: 0, fsm-cache: hit=1389997 m
iss=138671) ----
2010-03-31 19:46:03,169 - ubuntuone.SyncDaemon.DBus - DEBUG - called current_status
2010-03-31 19:46:07,309 - ubuntuone.SyncDaemon.DBus - DEBUG - Folders.delete: dbus.String(u'cfd7e79f-a376-4719-8cc2-be38
10ad48dd')
2010-03-31 19:46:07,310 - ubuntuone.SyncDaemon.VM - INFO - delete_volume: dbus.String(u'cfd7e79f-a376-4719-8cc2-be3810ad
48dd')
2010-03-31 19:46:07,310 - ubuntuone.SyncDaemon.ActionQueue - DEBUG - DeleteVolume share:--- node:--- DeleteVolume() queueing in the %s META_QUEUE
2010-03-31 19:47:17,958 - ubuntuone.SyncDaemon.Main - NOTE - ---- MARK (state: <State: 'QUEUE_MANAGER' (queues WORKING_ON_BOTH connection 'With User With Network')>; queues: metadata: 31499; content: 923; hash: 0, fsm-cache: hit=1389997 miss=138671) ----

And then the SD is stuck on WORKING_ON_BOTH with metadata: 31499.

The output of u1sdtool --waiting-metadata is extremely big (31500 lines), and the first ~950 lines are ListDir over the deleted volume:

ListDir(share_id=cfd7e79f-a376-4719-8cc2-be3810ad48dd, node_id=30e8bccd-7843-431a-8756-8b41cfe5b29f, server_hash=sha1:bc552c97e4545d9353a4fca6e11fd24c8867c8b1)