Unable to resolve file conflict in UDF

[Eric Casteleijn]

I have a file sort_mail.py in a UDF. Somehow a conflict arose for this file (which is strange, since I don't have any other machines syncing with U1 right now.)

When I rename the .u1conflict file to the original name, it is immediately renamed back to sort_mail.py.u1conflict. There seems to be no way to get the file back under the original name.

When trying to resolve this, I tried to disable synchronization for the folder from Nautilus, which silently failed as well.

Attaching logs.

[Eric Casteleijn (thisfred)]

This is the part of the log that is written when I rename the file back to the original and syncdaemon renames it back:

2011-05-13 12:40:46,162 - ubuntuone.SyncDaemon.Main - NOTE - ---- MARK (state: <State: 'QUEUE_MANAGER' (queues IDLE connection 'With User With Network')>; queue: 0; hash: 0) ----
2011-05-13 12:40:53,474 - ubuntuone.SyncDaemon.StorageClient - DEBUG - Ping! rtt: 0.062 segs
 2011-05-13 12:41:28,156 - ubuntuone.SyncDaemon.EQ - DEBUG - push_event: FS_FILE_CREATE, kwargs: {'path': '/home/eric/bin/sort_mail.py'}
2011-05-13 12:41:28,158 - ubuntuone.SyncDaemon.sync - DEBUG - T:SERVER:F 1647bfc0-2c2e-4af8-8a41-3212c3149fc9 ['5c084fb2-caa7-4020-a1bc-918611aad75b'::'9eb3bbc7-da1f-4461-aefa-f4562d53b9c8'] ''bin/sort_mail.py'' | EVENT: FS_FILE_CREATE:{} with ARGS:('/home/eric/bin/sort_mail.py',)
2011-05-13 12:41:28,160 - ubuntuone.SyncDaemon.sync - INFO - T:SERVER:F 1647bfc0-2c2e-4af8-8a41-3212c3149fc9 ['5c084fb2-caa7-4020-a1bc-918611aad75b'::'9eb3bbc7-da1f-4461-aefa-f4562d53b9c8'] ''bin/sort_mail.py'' | Calling nothing (got FS_FILE_CREATE:{})
2011-05-13 12:41:28,162 - ubuntuone.SyncDaemon.sync - DEBUG - T:SERVER:F 1647bfc0-2c2e-4af8-8a41-3212c3149fc9 ['5c084fb2-caa7-4020-a1bc-918611aad75b'::'9eb3bbc7-da1f-4461-aefa-f4562d53b9c8'] ''bin/sort_mail.py'' | Called nothing
2011-05-13 12:41:28,163 - ubuntuone.SyncDaemon.EQ - DEBUG - push_event: FS_FILE_CLOSE_WRITE, kwargs: {'path': '/home/eric/bin/sort_mail.py'}
2011-05-13 12:41:28,165 - ubuntuone.SyncDaemon.sync - DEBUG - T:SERVER:F 1647bfc0-2c2e-4af8-8a41-3212c3149fc9 ['5c084fb2-caa7-4020-a1bc-918611aad75b'::'9eb3bbc7-da1f-4461-aefa-f4562d53b9c8'] ''bin/sort_mail.py'' | EVENT: FS_FILE_CLOSE_WRITE:{} with ARGS:()
2011-05-13 12:41:28,167 - ubuntuone.SyncDaemon.sync - INFO - T:SERVER:F 1647bfc0-2c2e-4af8-8a41-3212c3149fc9 ['5c084fb2-caa7-4020-a1bc-918611aad75b'::'9eb3bbc7-da1f-4461-aefa-f4562d53b9c8'] ''bin/sort_mail.py'' | Calling calculate_hash (got FS_FILE_CLOSE_WRITE:{})
2011-05-13 12:41:28,167 - ubuntuone.SyncDaemon.HQ - DEBUG - HashQueue: inserting path '/home/eric/bin/sort_mail.py' mdid 1647bfc0-2c2e-4af8-8a41-3212c3149fc9
2011-05-13 12:41:28,168 - ubuntuone.SyncDaemon.HQ.hasher - DEBUG - Hasher: got file to hash: path '/home/eric/bin/sort_mail.py' mdid 1647bfc0-2c2e-4af8-8a41-3212c3149fc9
2011-05-13 12:41:28,168 - ubuntuone.SyncDaemon.HQ.hasher - DEBUG - Hasher: path hash pushed: path='/home/eric/bin/sort_mail.py' hash=sha1:ccf3f5ecd9786696ef57ad56a36cfc9a7300ea73 crc=270360920 size=3423 st_ino=12990046 st_size=3423 st_mtime=1305228529.1769295
2011-05-13 12:41:28,170 - ubuntuone.SyncDaemon.sync - DEBUG - T:SERVER:F 1647bfc0-2c2e-4af8-8a41-3212c3149fc9 ['5c084fb2-caa7-4020-a1bc-918611aad75b'::'9eb3bbc7-da1f-4461-aefa-f4562d53b9c8'] ''bin/sort_mail.py'' | Called calculate_hash
2011-05-13 12:41:28,171 - ubuntuone.SyncDaemon.EQ - DEBUG - push_event: HQ_HASH_NEW, kwargs: {'crc32': 270360920L, 'path': '/home/eric/bin/sort_mail.py', 'stat': posix.stat_result(st_mode=33261, st_ino=12990046L, st_dev=2053L, st_nlink=1, st_uid=1000, st_gid=1000, st_size=3423L, st_atime=1305283223, st_mtime=1305228529, st_ctime=1305283288), 'hash': 'sha1:ccf3f5ecd9786696ef57ad56a36cfc9a7300ea73', 'size':...

[Eric Casteleijn (thisfred)]

I think this was due to network/server problems. It resolved itself when an older version of the file was finally downloaded, after which I was able to merge the changes into it.

There is still the question of how a conflict could arise when there is only one client and one server, though. IIUC this should not happen, even in the face of network failure, though I can imagine a scenario where server problems could have caused this.