Recently, I spent some time organizing the contents of my Google Drive. I moved some .gdocx and .gsheetx files to new locations, and moved several folders containing such files as well. The odrive client made this very convenient, since I could drag and drop locally instead of using the Google Drive web interface.
Unfortunately, after reorganizing, many of the Google docs became invalid: Google Drive saw them as 0-byte files ending in that extension, rather than actual Google docs. And the original Google docs were in the trash. I was able to pull everything out of the trash using the web client, put things back where they should go, and delete all the bogus .gdocx and .gsheetx files, but the situation could have been much worse if I had not noticed right away.
The problem seems analogous to the one described here, except that I was only moving docs between folders of the same Google Drive account, which according to my understanding should work just fine.
In general, I get the impression that odrive sometimes deletes and reuploads files, rather than doing an atomic/efficient move operation. If so, that would explain why the .gdocx and .gsheetx files got corrupted: they were uploaded as normal non-Gdoc zero-byte files.
Why does odrive use zero-byte .gdocx and .gsheetx approach, rather than using the same format as the Google Drive client, with .gdoc and .gsheet extension containing the actual GDoc remote key for each file? The zero-byte approach seems much more fraught with peril, as evidenced by the above.
For now, I have unsynced my GDrive accounts from odrive, because this bug was way too scary, and switched back to the Google Drive client. But I actually have three GDrive accounts (basically 1=work1, 2=work2, 3=personal), and it would be much awesomer to use odrive since it handles multiple GDrive accounts, unlike Google’s Drive client.
Is this a known bug? Would it help for me to try to reproduce again?