Insync starting with empty directory

Bugs and issues Linux
#1

So I run Insync on Linux (Ubuntu 21.04) and ZFS, and I had an issue today that scared the hell out of me. Due to a failed drive my ZFS pool didn’t come up, and when Insync started it interpreted the missing data as “He went and deleted everything” and proceeded to delete everything from the cloud. Now thankfully that is something easily fixed, but I have to know if there is an easy way to tell Insync not to start if it doesn’t see the filesystem actually MOUNTED.

For my purposes I’ve changed the auto-start to refer to a script that looks for my data mountpoints before starting it, but feel like that’s a kludgy work-around that could be fixed more eqoquently in the code itself.

For the record (in case anyone needs it) I changed /usr/bin/insync to include the following:

#!/bin/bash
zfs list | grep DataPool > /dev/null ; rc=$?
while [ "${rc}" != "0" ] ; do
   echo "Waiting for ZFS"
   sleep 10
   zfs list | grep DataPool > /dev/null ; rc=$?
done
LC_TIME=C exec /usr/lib/insync/insync "$@"
#2

Hey @NettBeast!

That is such a scary thing indeed and my apologies for what happened! Is the ZFS filesystem your main sync location (base folder)? If so, Insync should ideally throw out a “base folder is missing prompt” if it isn’t able to detect the mounted filesystem, and not delete the whole thing.

Can you please send your logs.db and out.txt files to support@insynchq.com with the link to this post? Those should be in ~/.config/Insync.

Thank you very much for sharing what changes you had to make in /usr/bin/insync.

#3

Sent -

ZFS awareness / support needs to be included in new products… It’s an amazingly agile filesystsem and is gaining support right and left… I started using it last year and I’ll never go back.

1 Like
#4

That’s the problem with mount-points vs. directories. The ZFS filesystem is the root of the mountpoint, but if it’s unmounted, the mountpoint is still there regardless. That may be why insync thought the files IN the folder had been deleted, and not that the mount wasn’t there.

#5

That makes sense @NettBeast. Let me forward the logs you sent so we can check it out further.