Alias/Symlink files being moved to trash

Files stored in non-GoogleDrive folders are being deleted. The folders that are being affected are folders that have been included via the Finder context menu “Add to Insync”. (Not sure if the default behavior is to create an alias or symlink on OSX).

An example of one of the folders this issue is affecting…

Actual location of folder in question:
~/Music/

Location of alias/symlink within Google Drive folder:
~/Google Drive/Music

It also has affected folders whose alias/symlink entry moved, such as…

Actual location of folder:
~/Public/

Original location of alias/symlink:
~/Google Drive/Public/

NEW location, after I have moved it:
~/Google Drive/Shared/Public/

Now, it seems to be somewhat random in which files get deleted. It is not totally deleting the contents of a folder, but will delete entire contents of subfolders. As an example…

Within the folder (both locations shown below, actual followed by logical) every file has been deleted…

~/Music/Library/Tracks/
~/Google Drive/Music/Library/Tracks/

However, other subfolders are unaffected, such as this…

~/Music/Podcasts/
~/Google Drive/Music/Podcasts/

In regards to how the files are deleted, it is not deleting them individually, it deletes the top-level parent folder. Once they have been removed, I find an entry for the whole alias/symlink folder in Google Drive’s trash (on the web UI), which I can restore to recover my files, but it creates a new folder in my Google Drive. However, even though I find a copy of the top-level folder in Drive’s trash (“Music”), the local copy still exists on my machine ("~/Google Drive/Music/"), even with some of the files that have not (yet) been removed. The web UI will display it as having the same name, but the local version will appear with a “(2)” following the name – effectively creating a duplicate, though no data is actually duplicated. Instead, it will recreate the entire subfolder structure.

Additionally, this entire process appears to be able to start completely over, though I’m not sure of the trigger. Upon examining the web UI trash, I will actually find more than one copy of the symlink/alias’d folder. As an example…

When I restore the folders, I end up with several copies of the folder on my machine locally, such as:

~/Music/
~/Music (2)/
~/Music (3)/

Files that have been removed from the original alias/symlink folder can be found in either of the recovered folders. I have not noticed a pattern of which files are removed, it appears to be random.

I’ve experienced this issue a few times now, and both times the issue is accompanied by the “Can’t process *. - ‘NoneType’ object has no attribute ‘mtime’*” bug. In the client, I will see the list of errors grow into the thousands as this is occurring. Rebooting seems to quell this behavior temporarily, but the files still end up being removed.

Fortunately, it does not appear that any data is being permanently deleted.

I’ve been able to get the alias/symlink feature to work for short periods of time, both during times when the client has been in sync with the Google Drive’s servers, and when it is in the process of syncing data. It appears that housing files in non-GoogleDrive folder locations via alias/symlink is not a viable option at the moment. Any assistance you can lend me is appreciated.

Thank you.

Will be tagging our engineer @jimperio in this and he will get back to you :smile:

1 Like

@kvnkrklnd First off I’m sorry to hear you’ve been having such troubles with Insync.

We are investigating this issue currently, and have a few leads but still no definite fix.

Would you mind trying this test build to see whether the issue stops occurring? https://drive.google.com/file/d/0BwdTGfuY-IV9M0FJOHdkc0VoQ00/view?usp=sharing

If it still occurs, could you send your logs.db and the “dbs” folder in the same location to support@insynchq.com so that we may troubleshoot further? Thank you.

1 Like

Just emailed over a link for my logs folder.

Since my original post, the problem had gotten worse, duplicating each of the folders in question 5+ times. So I ended up moving my files out of those folders, merging them, then removing those folders entirely.

But I’ve gone ahead and recreated the scenario with one folder, which we can use as a guinea pig. I’ll report back if I notice the same behavior again.

Thanks!
-KK

I’m having the same issue. Any time I modify a file that I have symlinked into my Insync folder, the symlink gets deleted. This is happening on Linux.

Sadly this issue appears to still be occurring.

I tested with the following folders for weeks successfully…

~/Desktop/ (8 files)
~/Movies/ (3 files)
~/Shared/ (2 files)
~/Documents/ (400 files)

It was working with those, so I proceeded onto the largest folder I had symlinked…

~/Music/ (42,000 files)

It worked for a few hours, but after a reboot it decided to decouple the connection between the local files and their entries within Google Drive. The gdrive web UI showed that everything within all symlinked folders (Music, Movies, Documents, etc), and the folders themselves, had been moved to Trash.

The local locations of the files did not change, nor were they moved to the trash on OSX, but they were no longer accessible in their corresponding locations in the cloud. Once I realized this was going on, I moved the files from the symlinked folders into new folders I created in my Google Drive folder (not symlinked). This only had the effect of beginning to upload the files again.

Instead of reuploading nearly 1TB of data, I’ve opted to restore the folders from the Web UI’s trash, and redownload them.

Any word if you all are close to a solution on this one?

Thanks,
K

Same issue here - not cool to open your Documents folder and find only one folder left, and even that be mostly empty!!

The folders were moved to .insync-trash on my laptop, deleted from Google Drive, and somehow not deleted from my desktop (though I haven’t checked everything yet).

Is there a fix here?

@Josh_Hill Apologies for not replying sooner. Please send your logs to support@insynchq.com for investigation: How to find the log files.