Deleting entire Google drive is not sane behaviour

Bugs and issues Linux
#1

Hi, I just experienced some weird syncing issues and wanted to start from fresh.

So I stopped insync, renamed my root drive folder, created a new empty folder and started insync again.

I naively thought that insync would recognize this as a brand new folder that needed to sync from cloud -> local.

Instead insync decided that i had deleted my entire google drive, which moved ~3000 files to the trash bin.

I’m still picking up the pieces, and I am fairly shocked that you have no failsafe to prevent this kind of mistake.

ffs. how can you start deleting EVERYTHING without so much as a prompt asking the user to confirm?!

I have since understood start that in order to get a freshly synced folder, i must delete my entire insync config folder. that is not… user friendly lets say…

For now insync is uninstalled to avoid further damage. And I am debating whether to reinstalling it again. Especially after reading a lot of post regarding wild deletion behavior from the last year or so.

3 Likes
#2

Thanks for reporting this @Emillynge24. This sounds like a potential bug – Insync should bring up an error message if you renamed your base folder while it’s not running.

Tried it on my Mac:
43%20PM

It also shouldn’t have deleted your files. We’ll investigate this! If you haven’t already, please send an email to support@insynchq.com with your log files as it may help with the investigation. cc @jaduenas

1 Like
#3

@gio to be clear: I renamed the root folder and created an empty folder in its place.
This was done in the hope that insync would start over from scratch and do an initial sync.

1 Like
#4

Your new versions are RUBBISH and UNTESTED … yesterday all syncing stopped … nothing updated and was working perfectly. Now broken. Then I check AUR and there is an update so I updated … still NO syncing … really I paid for this great software which since version 3 is utter rubbish. My entire workday revolves around Drive and you have severely broken it. Fire your developers or at least go back to versions that worked. You are getting as bad as Google, Facebook and Twitter who break more than they fix. I have lost 5 hours yesterday and 4 hours today and STILL I cannot get anything to sync. Unsyncing and Resyncing 80+ GB is the only thing that works and then it break again later. Seriously disappointed in this product I paid for. Used to be great now it sucks !!!

2 Likes
#5

Same problem here. I stopped using Insync and waiting till I have time to clear all the duplicate or missing files and folder from an offline backup. Also remarks that I send logs and try to find a solution with support people but without finding.

1 Like
#6

Were you also attempting to rename your base folder?

#7
  1. stop insync
  2. mv ~/gdrive ~/gdrive.bak
  3. mkdir ~/gdrive
  4. start insync

Insync then started deleting all files on cloud.

1 Like
#8

I see. Thanks for this additional info, to confirm you have send your logs to support?

#9

I had the same problem yesterday using version 3.0.25.40643. I accidentally deleted the local folder and Insync deleted everything from my Google Drive. This was also on Linux.
This is a very serious issue! Fortunately i have a backup.
Now while re-uploading everything it does not get past some files. Just stays at 0 bytes. For hours. I have restarted it multiple times. Doesn’t help.

1 Like
#10

Similar issues here, too. Insync started sending my whole drive to .Trash-1000 until I stopped it, leaving me with half my files in the trash, impossibly sorted.

Also, Insync should have bug reporting built into their “fancy” new version 3 rather than the unsystematic route of asking every other person who manages to find this forum and complains to kindly send their logs.

#11

Nasty. I’d imagine the “correct” way to do it would be to stop insync. Rename the old folder. Start insync and change the synced folder to the new folder. Now create a new folder with the previous name. Now change insync’s sync folder to the new folder. But don’t quote me on that. :slight_smile:

1 Like
#12

Hi there, you are correct. This is in the works and will be coming out before this year ends. Thanks for the suggestion!

#13

Hello all—

We just released 3.0.28 here.

Please note that there are no autoupdates and this is not in the Linux repos yet since it’s an early Forums release.

#14

Insync v3.2.7.40868 on Kubuntu 20.04 just decided to move all of my Google Drive (in the Cloud) to the bin (in the Cloud). I think that’s because the sync’d version of the files on my laptop was on a USB-C drive that wasn’t yet mounted when the OS rebooted and Insyc started up.
That’s 1.2 TiB in 202,960 files moved to the bin.
Disastrous.
Yes, Deleting entire Google drive is not sane behaviour. Thank you very much Insync. If I ever recover from this mess, there’s one piece of software that is definitely going in the bin.

#15

Hi @AndrewJens,

I apologize for the whole fiasco! This should definitely not happen if your USB hasn’t been mounted yet (where the sync location is). When you startup Insync it should give a prompt that Base Folder is missing and wil resume once you mount.

If you can, could you please send the following to support@insynchq.com with the link to this post:

  • logs.db
  • out.txt
  • data folder
  • live folder

These are located in ~/.config/Insync.

#16

Hi,

Just wondering if anything came of all of this (after sharing my log files with support)?

It should be really simple: regardless of what other features that remain in the product, could you just implement an optional “god” mode that will not touch Clound storage unless you specifically give it permission. E.g. it will (on demand) produce a UI report of discrepancies between the local storage and the Cloud, and give you the option of what to do, e.g. delete the local files/folders, or upload them to the Cloud to get things back in sync (although I’m not sure about that option since things could be uploaded via the OS).

I guess that downloading from the Cloud to the local sync’d folder could always be permitted (to get things back in sync)?

As long as the Cloud files are never touched without explicit local permission/action.

Remember, some of us serve files (e.g. Google Docs Spreadsheets) to clients, so it simply cannot ever go wrong.

Cheers,
Andrew.