Comment 4 for bug 561587

I'm marking as confirmed for the following reason:

I met up with rye (Roman) at UDS and he was able to fix the issue and explain what the problem was. This is actually a duplicate of another bug, but I do not have the bug number to mark this appropriately. Roman may know what bug this is related to.

The root cause is apparently in the way u1sdtool hashes the directories before syncing. Apparently, what happens in some cases is that the hash is made of the cloud source directory and if the sync fails for whatever reason, it's never started again, until something changes that causes the hash to change. Even trying to force u1sdtool to refresh a subscribed directory fails, as the hash never actually changes.

Roman knows exactly what the issue is, and the very simple fix he showed me was to just touch a placeholder file in the local directory and then restart the syncdaemon. This changes the hash and forces a refresh, and the files then get transferred properly.

I believe he said that this will be fixed in an SRU for either u1sdtool or syncdaemon itself.

Roman: if you see this, thanks again for helping me sort this out at UDS, and for the explanation about what was going on. If you happen to know what bug number is appropriate, could you mark this as a duplicate?