I have been a satisfied paid member of the oDrive community for a few years now. No significant issues experienced to date.
I regularly sync large numbers of video files in folders. To free up space, I normally unsync folders as the Windows folder icons suggest that sync’ing is complete. I have seen instances when the Windows folder icon was incorrectly telling me that syncing was complete. ODrive would show me an error which stops me from unsyncing. A little annoying but it protected my data from being lost.
Today I was syncing a large number of video files and when I attempted to unsync, I got an error saying a sync error occurred and my sub-folders and video files had disappeared. No evidence of those files in the ODrive trash bin or the Windows recycle bin.
Interestingly (and it’s good news) once the full sync had completed, the unsynch’d files reappeared. I.e. the .cloud files. So ODrive clearly had everything under control. I don’t know whether the bug is in ODrive or there was just an issue with the Windows folder. Ultimately I got the impression that all was lost.
Hi @nigel1,
I am really glad to hear that there was no data loss!
We’ve tried to make every effort to account for unexpected errors when unsyncing to ensure data safety.
It looks like odrive may have hit a filesystem error when converting the files back to placeholders which then prevented it from completing the operation. This can leave the folder is a strange visual state for a while, even if odrive still understands the correct states, internally.
Can you send a diagnostic from the odrive menu, if you get chance? I would like to see if this error was captured and if we can handle it better.
Thanks @nigel1!
I wonder if this was a race condition, where one of the files inside the folder was still in the process of being deleted, even though Windows returned a successful response to the delete request. odrive would then try to delete the folder and replace it with a placeholder, but Windows reports that the folder is not empty.
I noticed this is on D: drive. Is that a standard internal drive on your system? I’m just wondering if there could be something about the drive that causes some additional latency.
We may just need to retry in these scenarios if we hit a filesystem exception. Reading up on the underlying, low-level operations, it is possible to hit a race condition where Windows accepts the delete operation, but doesn’t actually execute it immediately.
