I would like to be able to view my pending deletes. ODrive. It still makes me nervous every time I see Empty Trash and Sync Deletes in the ODrive menu. I haven’t done an empty trash in forever because of the fear that ODrive has picked up a file I didn’t mean to delete. And of course there’s still no way to mass-un-delete, which I mentioned way back in Sept 2016.
The odrive menu can defintiely fall short of details for trash, especially if you’ve built up a large list of pending deletes. You can use the CLI status commands for a details listing of each item’s path to get an exact accounting of what is in that trash list:
You would want to use the
status --trash command
Seeing the files that were pending delete was never the problem. I could do that from the tray icon. I want to be able to check and view the actual files.
So, what you have here is not actually the solution, it’s just another way to look at the list of file names.
A pending delete is when odrive detects that a local file has been deleted. The sync engine wants to sync this change and delete the corresponding remote file, but the odrive trash is a safeguard that holds that delete commit until the user confirms it.
There aren’t any physical files to see because they are no longer on the local system. If you want to check these files you would need to look at them on the remote side using the storage service’s web client or the odrive web client.
Yeah, but I’m paranoid. I want to be able to open/view the files and make sure it was really, really something I wanted to delete (like the Windows Recycle Bin) before I pull the trigger and delete them once and for all.
It seems like it should be something trivial to just show me a thumbnail of the file/image I have pending deletion.
At the time of the original request I had some weird hard disk trouble and I was afraid the dozens of files that were pending deletion were not really intentionally removed.
Thanks for the clarification.
A little more on how odrive works:
The odrive sync engine monitors the local filesystem to detect changes. For example, it will look at a folder and retain the information of the current items in that folder. When it looks at that folder later, it will determine what has changed (if anything). In the case of local deletes, odrive will identify that a file is now missing from where it once was.
odrive isn’t involved in the local delete, so there isn’t a way for odrive to intervene in that delete operation to stop it, or copy the file to another location for a backup. It detects the delete by identifying the absence of the file, as which point it has no way to try to prevent the local delete, or even know why it was deleted.
Now that the delete has been identified locally because the file no longer exists, the sync engine will want to sync that delete to the remote storage (and delete the file there). There is where odrive implements the odrive trash as a last line of defense against unintended deletes. It holds off on sending that delete command to the remote storage until the user confirms the operation (by emptying the trash). At this point the only thing odrive can do is:
- List the contents of the odrive trash
- Empty the contents in the odrive trash, which will send the delete commands to the remote storage
- Restore the contents from the odrive trash, which will bring back the item(s) as placeholder files (.cloud/.cloudf), which represents the remote objects and can then be downloaded locally, if desired.