I recently purchased O Drive premium. It is connected to an Amazon Cloud Drive account.
I installed Desktop Sync on my iMac (10.12.1) and set a directory (located on a thunderbolt RAID enclosure) as an external sync folder. It’s a pretty big directory — about 4.5TB.
My up-speed is 200Mbps.
I left it going overnight and it was still going all the next day as I worked (which was as expected, my estimate was ~52 hours best case scenario) however, at the end of the day — completely out of habit — while the sync was still in progress I shut down the computer before going home.
It was my expectation that this morning I would be able to boot up and that O Drive Desktop Sync would simply continue the big upload.
Instead, O Drive Desktop Sync closes after 3 or 4 seconds. Every time I try and open it again, it just closes after 3 or 4 seconds. I’ve shut down the iMac and turned it back on, and O Drive’s behaviour continues.
Can you check to see if there are any crash reports generated when this happens? You can look for one from the console (type console into Spotlight search) and then navigate to the “User Diagnostic Reports” section. If you can send a couple to me (if they exist), I can see if anything stands out.
Hi @alastair.tye.samson,
If this is what I think it is (the crash report indicates it probably is), we have seen this issue pop up occasionally, although we haven’t found a definitive solution for it yet. The root is that MacOS is sending information to us in a format it is not supposed to and this unexpected data causes problems.
The cause seems to be linked to external drives. Can you see if odrive starts up if you disconnect your external drive. If so, see if it continues running once you reconnect the drive. Once the drive is reconnected, go to the “sync to odrive” listing in the odrive menu and click on the mount(s) that you have on that external drive. They will likely have a “missing” designation, since odrive can’t find the path.
Hmm, okay. I need to look into this more then. This should’ve worked to prevent fsevents on that drive, which is what seems to be the root of this issue.
I suppose it is possible that there are still some events cached in there, and those are still being read.
Can you try removing the .fseventsd folder completely from the drive, then creating an empty .fseventsd folder and an empty no_log file inside? Then disconnect the drive, start up odrive, and then plug the drive back in and see if it is any better. If it crashes again, see if there is anything new in the .fseventsd folder.
Hi @alastair.tye.samson,
I looked at this some more and it looks like the no_log parameter will only disable the caching of events on the Volume, but not the real-time events, themselves. It also doesn’t seem to work quite right, anyway, from my testing.
Here is a alternative workaround to hopefully get you back syncing. With odrive not running (not difficult in your case), run this terminal command: sudo launchctl unload /System/Library/LaunchDaemons/com.apple.fseventsd.plist
This will stop the fsevents daemon. Start odrive, which should start up and run normally. Make sure syncing has resumed. You should then be able to start the fsevents daemon again with this command: sudo launchctl load /System/Library/LaunchDaemons/com.apple.fseventsd.plist
Since odrive sets up its listener at the start, it will not be tapped into fsevents and, subsequently, MacOS can’t send the malformed events for the external drive to odrive. Not ideal, but I believe it should work.