What is the most effective way to CORRUPT all of the data on a Crypt remote? Google Drive

What is the problem you are having with rclone?

I have about 1TB in an encrypted Google Drive remote. I regularly delete, then restore this content, due to a lack of self control. I need a way to delete it such that it is not recoverable, or that the recovery process would be so ridiculous that it isn't worth the effort. Currently, I'm running a while loop to overwrite the files with 0b empty placeholder files with the same name. I got a file list using rclone lsf -R crypt: > file-list.txt and I'm just uploading that over and over. It's very slow since there's over a quarter million files total. I'm thinking that maybe rclone moveto would work, is that right?

For example, if I were to open the gdrive: remote, not where I can see the decrypted file names, etc... Could I simply use rclone moveto and pipe a list of all the encrypted files in, and rename them sequentially or randomly, wouldn't that make it impossible to access later? And Google Drive wouldn't see that as a delete, but a rename, so restoring it after deletion would preserve the new name and not the old name, and my crypt keys wouldn't work anymore since the encrypted file names have changed.
That sounds less expensive than 100+ upload passes of over a quarter million blank files.

Run the command 'rclone version' and share the full output of the command.

rclone --version
rclone v1.57.0

  • os/version: ubuntu 20.04 (64 bit)
  • os/kernel: 5.11.0-46-generic (x86_64)
  • os/type: linux
  • os/arch: amd64
  • go/version: go1.17.2
  • go/linking: static
  • go/tags: none

Which cloud storage system are you using? (eg Google Drive)

Google Drive, data is stored in a Crypt remote

The command you were trying to run (eg rclone copy /tmp remote:tmp)

while [ $count -lt 102 ]
echo "STARTING PASS $count"
while read a; do touch "$a"; done<file-list.txt
rclone move . crypt: --no-check-dest --exclude file-list.txt -P
let "count=count+1"

I realize that the top of this post says "No Exceptions" but I figure I'll post configs and logs only if its human-requested here. Rclone is working, I just need methodology advice.


Did some of the keywords in my post cause me to get filtered by the spambot? What happened here?

Can you just use the WebGUI:

  1. Delete folder
  2. Empty Trash

and it would be gone. What's the goal of renaming it and doing all that as opposed to just deleting it?

Due to a personal problem, that doesn't work for me. I end up (during moments of weakness) logging in to google admin and restoring the deleted files. They don't delete forever until after 30 days. The goal behind renaming it is that, even after I've deleted it, if I restore it... it wouldn't be useful or accessible.

Hi doknobipso-vusra,

Your reasons seem legitimate, but in case there is an answer to your question then it would also be the answer to this question:

What is the perfect perfect way to perform a ransomware attach on Google Drive?

I therefore suggest you/we think in alternatives.

@Animosity022 Perhaps we move this to off-topic?

1 Like

Are you using a team drive or something? I always thought once you deleted from trash, it was gone forever at that point as it gives you a ton of warnings about that.

I don't have a GSuite anymore so I can't see myself.


let's say the root folder is named stuff
perhaps rename the root folder to do not restore-stuff and then purge it.

that way, if you go into the trash, you can see not to restore that folder

Welcome to data hoarders anonymous! :pleading_face:

Good idea, but it will only work if you have some willpower left - it will not help the severely addicted.

Think of "do not drink" on bottles or "do not smoke" on cigarettes.

The best I can come up with is to hand-over the (admin) credentials to someone you trust (to hand them back after 1 month) and then ask them to change password, 2FA and recovery codes.

1 Like

or somehow get permanently rid of the passwords used for the encryption.

well, seems all the best of the rclone forum, are here and still we are helpless to over come, human nature, and lack of willpower.

perhaps we can create an undocumented rclone command and ask the rcloner to execute it.
rclone implant memory rcloner:
to implant a subconscious memory, into the innocent, unknowing rcloner, to do or not to do a certain action.

of course, if the rcloner is suffering from clickatosis,
then there is no hope, the rcloner will continue to restore that folder.

clickatosis, is a disease that dr. jojo discovered decades ago and has dedicated his life to find a cure.
clickatosis, or known in the common vernacular, as click crazy, is a mental condition, where the patient cannot control their click reflexes, will click on anything at anytime.

1 Like

This made me click the LIKE button, uncontrollably.

But not to detract any further, I'll be the first to acknowledge that an obsession with digital data is something to be taken seriously.

1 Like

yes, your case is a good example of something dr.jojo has documented.

that clickatosis is just a modern diagnosis, a new name, for the condition has has plagued humans for since the dawn of man.
in the days of old, the underlying condition, has been observed in outlaws, who could not control their reflex to shoot their guns at anything at anytime.

Now please be kind and on subject, somebody seems to have a problem to be taken seriously.

1 Like

True, except perhaps this is slightly different since I'm wanting to corrupt only what I've got encrypted. Excellent point though, I wouldn't want to provide ransomware attackers with another vector idea of any kind, esp. not with my favorite software rclone!

It isn't a team drive, but with an admin account data can be restored even if deleted from trash.

I may do this as an absolute last resort.

Unfortunately, I cannot forget the password and salt that I used. That's why I thought renaming the files might help, because then the password and salt won't be able to read them. Do you know if that's a correct assumption?

There is a memory remote but unfortunately it cannot access my own memory, just my computer. Maybe ncw can work on extending this to the device that exists between keyboard and chair.

I appreciate that. I'm trying to destroy an addiction here.

Thank you.

Current solution:

leave the while loop running until it has overwritten 100 times. This'll take a very long time. I may stop this process and try the moveto solution as well. I'll probably do that on the unencrypted gdrive: remote, but on the encrypted files (file names are encrypted) so I think that, after moving everything, I won't be able to use the rclone password and salt to view any of the files post-rename.
For any that are curious, the reason for 100 overwrites is that Google Drive will store up to 100 revisions of any file. So, while I can restore things deleted from trash from the last 30 days, I can't restore a file to a version from over 100 revisions prior to now.

Hah, that's part of the problem for sure! I've gotten far too clever at means and methods for hoarding massive amounts quickly using scripts and servers, etc. Then I started hoarding data that's harmful to my mental health and my relationship health, and I need to destroy the data. The addiction is unfair, it restores my data when I don't want it to. That's why I have to corrupt it all while the dopamine cravings aren't overwriting my right mind.

Google Drive application itself supports differential sync. You could use a windows computer, and corrupt your files by appending (or changing) a random number of bytes to each file. And disabling versioning so you can't restore it.

Trying to think outside the box. Another would be to change the encryption keys for another random and move the data, but as you mentioned it's a lot of data it won't help.

Too bad the encryption key is something you know and not something random you can just delete and lose access.

Final Solution:

Just to wrap this thread up, I figured I'd give my final solution. After a few passes of overwriting blank files, I also used moveto on the top level directories within the crypt remote, but on the regular remote.

So, my encrypted folder name underwent a rename like 4oqeruiasrhliqf24pwoi > 0 which causes the encrypted remote to no longer be able to read it.

From there, I delete the folder named 0 and move to the next folder, all the way on through. That way, after everything is deleted, in gdrive trash (and beyond) all the folders are named 0. It would be an immense amount of work to log into google admin, restore the files, then attempt to recover the old directory names from their original names, then decrypt.

I could have added another layer to this, by renaming all of the files inside the crypt remote, but I think for now what I'm doing should suffice. Time to make it a full month without this data, finally!

1 Like

Best of luck, if you can/want have a friend you trust hold the admin console password from you for a month, that way you won't be able to recover the content even in the darkest hour. Remember it's always ok to ask for help.

Interesting idea, I didn't know you can disable versioning. But then, how would that happen? Wouldn't it version the file when it syncs? I guess I don't understand what differential sync does. Also, getting access to a Windows PC is a challenge. I'd probably have to run it in a VM or something.

Yes, a real bummer.

Wouldn't that just leave the original data in the trash, though? A move from crypt1: to crypt2: on the same gdrive account wouldn't happen server-side, unless I'm mistaken. It would be a copy then delete operation. Files would still exist and be recovered by someone sinister (me on dopamine high).


As a final precaution, I created 1,000 directories, each with one empty text file inside, and uploaded all that to crypt:

Next, I repeated the rclone moveto gdrive:crypt/3wqpgeoiahls98w53 gdrive:crypt/0 operation on the non-encrypted gdrive: directory that has all the encrypted folder names. After that, I used rclone purge gdrive:crypt/0 until all 1000 directories had been moved to the trash.

Finally, Empty Trash

In the event that I tried to restore ANY of this... I would have over a thousand directories all named 0, most of which were not my regrettable content. Sorting out that mess would be a total nightmare, and I know there's no way I'll do that.

Thanks to everyone who gave input. It's been an adventure.