The odrive trash isn’t storing anything physical. All it is doing is holding the delete command from going to the cloud, until you say to send it. Entries end up in that queue when files that exist in your cloud storage are deleted on your local system. When that happens, odrive picks up that the file is now gone and stores the potential delete command for the cloud in the “odrive trash”. When you empty the trash, odrive send the command to the cloud storage to delete that file. If you choose to “restore” the file, it adds back the placeholder file (.cloud) locally, where it was deleted.
In the case of Google Drive’s “Shared with me” folder: If you end up deleting an item locally in the “Shared With Me” folder, it is, again, sent to the “odrive trash”. When you choose to empty the trash, odrive tries to tell Google Drive to delete that file. Google responds back and says that your user does not have permission to delete that file. When that happens odrive “restores” the file by adding the placeholder back to where it was originally deleted locally. This is done so that the file is not stuck, invisible, in the odrive trash. Since you can’t delete it, it is put back where it belongs.
Does that make sense?
So your options for clearing files in the “odrive trash” that are not allowed to be deleted in the cloud is to:
Restore them
Remove them from the share from Google Drive’s web client. You can do this by right-clicking on the file and selecting “Remove”.
It is not a “shared with me folder” it is “my drive” on google drive?
Anyway, I have 3 google drive folders (different accounts), one dropbox folder and one OneDrive folder linked to odrive. As far as I understand, the physical files reside on my pc and odrive syncs the files to the cloud??? Correct?
If I uninstall odrive, will the physical files remain on my pc or will they be left somewhere in the cloud?
For the files you are having trouble with, are they listed as being owned by you or owned by someone else? You can see this in Google Drive’s web client, like so:
I was using “Shared With Me” as a reference point, but you can have files that have been shared with you anywhere within Google Drive.
If the files that are throwing the permission’s error are owned by you, then this may be a different issue (unless they are inside a folder that you do not own and have removed write permissions, for example).
For syncing, odrive will sync any new or changed files that you place into the odrive folder to the cloud. It also give you the opportunity to sync down (download) files from the cloud. You probably noticed that odrive started out with all placeholder files (.cloud and .cloudf). These represent your cloud data without taking up space on your system. You can then download those files/folders, if you wish, to create a copy of the data on your local machine. If those copies are changed locally, then odrive will sync those changes back to the cloud, etc…
If you uninstall odrive, the data will remain in the cloud and the data locally will remain as it exists at the time of uninstall, but they will not longer be linked, of course.
I am the owner of the files and the folders. It looks to me as if I will not get this resolved unless I upgrade my subscription?
I just attempted to delete a file from the trash by right clicking it, it asks if I want to restore or delete - I select delete, A few seconds later I get the “you have restored this file, but you do not have edit permissions.”
Reading the manual, the descriptions about empty trash etc are very different to my “free” system.
My concern with uninstalling odrive is that all my data is now in the odrive cloud as well - yes or no? I thought when I first installed odrive and linked my google drives to it, that copies of my data would still only reside in/on the respective google drive locations (In the cloud somewhere I suppose)
I think I am going to have to go back to native google drive, even though odrive makes life easier everywhere else, I cannot go on getting more and more files in the trash that I cannot empty.
Hi @logistics,
Emptying the trash doesn’t require a premium account. The only thing trash-related that requires Premium is auto empty trash.
Keep in mind that the errors you are seeing are actually coming from Google Drive. We are sending it a command and it is telling us that your user doesn’t have permission to do that action. We are trying to make it happen, but Google isn’t letting us
We don’t store any of your data. We just allow you to link to your data and access and manage it better where it resides. When you are syncing your data, the odrive client is uploading/download directly to the linked storage.
For this trash issue, can you please do the following so I can take a deeper look:
Reproduce the “you have restored this file, but you do not have edit permissions.” message again and take a screenshot of it.
The reason there are so many deleted files from the quotes folder is that we had too many quotes going back to 2013. I then created sub folders in the quotes folder, 2013, 2014 etc and moved the relevant files into the sub folders.
This was all updated properly on google drive, as the other users who only use the google interface, then saw all the changes I made and on their side, all is well.
Tony, when you say here that odrive sends the command to the cloud storage to delete the file, I am a bit confused as the file is no longer physically in that cloud storage location? All odrive should do, surely, is to remove the pointer to the deleted file that it is holding in the trash folder. Or am I being a bit too simplistic? - what i mean, is that odrive does not have to ask google drive if it can delete the file, google drive has already deleted it. And the instruction to google drive, to delete the file, was actually sent, received and acted upon by google drive, via odrive. As far as google drive is concerned, the transaction is complete. There are no files (or pointers) in google drive trash relating to the delete.
OR
When I delete a google drive file via odrive, odrive should let google hold it in google trash folder and forget about it. That way I could go to google drive and empty its trash, (If it did not do it automatically)
Anyway, did you glean any information from the last diagnostic?
Hi @logistics,
I am taking a look through the diagnostics. When things are in the odrive trash it should be because the files still exist in the cloud but it was noted that they were removed locally. The diagnostics only go back a little ways, so I can’t see the historical events that led up to this point.
It looks like all of the odrive trash files are in “Google Drive (Aqua)/Aqua Africa”. A shortcut here is to just right-click->unsync the “C:/Users/Basil/odrive/Google Drive (Aqua)/Aqua Africa” folder. That will clear the odrive trash queue of any items in “Google Drive (Aqua)/Aqua Africa” and turn C:/Users/Basil/odrive/Google Drive (Aqua)/Aqua Africa into a placeholder (C:/Users/Basil/odrive/Google Drive (Aqua)/Aqua Africa.cloudf).
I think that should bring things back into a more consistent state.
I also noticed you have a folder inside the odrive folder that doesn’t appear to be a linked account:
“C:/Users/Basil/odrive/Odrive Problem”
You cannot place anything in the root of the C:/Users/Basil/odrive folder because there is no storage backing it. odrive does not store any files, so there is nowhere for that folder to be uploaded. You will need to move that folder elsewhere.
If you are curious about the “insufficient permissions” error, this is an example of what Google is sending back when trying to send the delete for some of these files:
07:44:59PM None 9140 RAISED apply_remote_delete_file Google Drive (Aqua)/Aqua Africa/Sales/Sales Invoices/AAL-171 Mukuba Mall.xlsx’]) --> SyncAdapterRequestException(code GD_EDIT_PERMISSION_DENIED caused by GoogleDriveApiException(httpStatus 403 - {
“error”: {
“errors”: [
{
“domain”: “global”,
“reason”: “forbidden”,
“message”: “Insufficient permissions for this file”,
“locationType”: “other”,
“location”: “file.permissions”
}
],
“code”: 403,
“message”: “Insufficient permissions for this file”
}
}
Hi @logistics,
Since you are using the free version, as a workaround, you can move the folder out of odrive, instead (to your desktop, for example). That should pop-up a message saying that you can’t move the folder outside of odrive because it contains placeholders. odrive will then add back the a placeholder for the “Google Drive (Aqua)/Aqua Africa” folder which will now appear as “Google Drive (Aqua)/Aqua Africa.cloudf”.
Once you have “reset” the folder in this way, you can expand it again and add your new/changed files to that folder to be uploaded, as normal. Is that what you mean?
I did what you suggested but I did not get a message about not being able to move the folder outside of odrive and I did not see a new placeholder for the Aqua Africa folder.
I ended up going back to the native Google Drive setup and re-synced the aqua folder via google drive. I also unlinked the aqua folder from odrive.
Life is just too busy right now to continue playing with this as the aqua folder is very busy and the updates are crucial to our business. Not to mention the bandwidth that gets eaten up by a major re-sync of 8Gb of data each time I move or mess with the location of the folder.
Thanks again for all the help and I think I am going to call it a day. $96 odd may not seem like a lot but I cannot justify spending that on a convenience!!
I know this an old thread but I am just wondering if there has been any resolution with this issue.
I too am still unable to ‘empty odrive trash’ files that are in a shared google drive folder.
I realise its google drive permission that are blocking the delete but have you guys worked out a way around this?
Hi @craig2,
I actually just took a look at this and Google still hasn’t exposed a way to remove shared items via the API.
I took a look at what they are doing on the webclient hoping we might be able to use some undocumented method. They are using their v2internal API endpoint and modifying the file metadata to set “subscribed” to false. I tried to set this with the public API, but it had no effect and we aren’t allowed to use their private API…
We could change it so that trying to trash shared items just fails silently, instead of popping an error, so that it doesn’t interrupt the rest of the empty trash process, but it looks like that is the extent to which we could change the current behavior, unfortunately.
