Send files to OS trash mechanism on delete #1968
Conversation
This adds a config option, defaulting to use trash, and adds a dependency on the pure-Python 'send2trash' package. Linux, Mac and Windows should all be supported. Alternatively, we could make it default to hard delete (the current behaviour), and let users opt in to trash behaviour. Then Send2Trash could be a soft dependency. This doesn't touch the UI yet, so you still get a confirmation dialog which inaccurately says it will 'permanently delete' the file. If we want to do this, we'll need some way for the contents manager to pass the UI a hint about whether deleting is permanent or not. Closes jupytergh-165
|
I think a lot of people would be happy about this, so I would say that it makes sense as a default. One case where this might not be sufficient is a hosted service where the notebook server is the only window on the system (e.g. JupyterHub, cloud services). In these cases, without a read API for the trash, you get something in the middle: lost access to files, but the data isn't actually cleaned up. But then again, trash is really something along the lines of a |
|
This still seems like there's enough to work out that I'm bumping it to 5.1. |
|
5.1 is approaching, and there's still quite a bit of work to do. Bumping to backlog. |
|
@takluyver It would be great to ship this! What more needs to be done? |
|
To enable it by default, we'd need a way to get files back from the trash, I think. The major platforms have different trash mechanisms, so that's not straightforward. To make it an off-by-default option, which offers much less benefit, we'd need a way for the frontend to know whether 'delete' is hard or soft, so that the UI can display appropriate information. |
|
Looking at some of the issues open on send2trash (arsenetar/send2trash#9, arsenetar/send2trash#2), and thinking a bit about the complexity of the operation in general, I suspect that this would be an ongoing source of problems which we have little ability to fix. I'm not sure whether that outweighs the benefits. One option would be to define our own trash mechanism separate from the system recycle bin. But I suspect that there's a bunch of complexity we haven't thought about, with things like network filesystems, folders shared with VMs/containers, and folders synced by things like Dropbox. It would also be annoying for people who actually want to delete things if those things were neither deleted nor placed in the normal trash. |
|
I hear ya. It sounds like an elegant solution for the common user (because they can always recover the notebook from the trash) but I'm sue there are many edge cases where this fails. |
|
👍 on trying this out in 5.1, for me. |
|
Do you think we should try to do UI changes for 5.1, or leave the UI as is, with no mention of trash? |
|
Since there's a server-side flag and we have no UI of our own for recovering things from the trash, I think it's okay as-is for now. |
|
Travis failures are due to a bug in Send2Trash, fixed by arsenetar/send2trash#12 . I've asked for a new release there. |
|
Optimistically tagged as 5.1 - we're waiting on a new release of send2trash before we can do this. If we're ready to release first, bump this to 5.2. |
|
There's a new release of send2trash - re-triggering tests. |
|
Re-running tests with send2trash 1.4.1. |
|
Tests are passing, but I think it's still best to merge this after the release, so we can test it in master for a while. |
|
5.1 is now out, if we want to come back to this. As a reminder, this PR currently:
|
|
I just tested and it works for me on macOS 10.12.6. I think this is heaps better than permanently deleting files be default. I imagine it would be really painful to accidentally delete some important notebooks and files and not be able to recover them. It's much less painful to be required to go to the trash to permanently delete files. I vote to merge! |
|
Would love to get this in 5.2, but I think it still requires a little more review/testing. Marking as 5.3 for now... |
|
Imagine having a class of new users... please give us a countdown so that we can celebrate the coming of this feature :) |
|
I think the plan was to merge it just after 5.1 so it was in master for a while. We missed doing that, and we're releasing 5.2 sooner than expected, so I guess the new plan is to merge it soon after 5.2 so that it's in master for a while before 5.3. |
|
Roger that @takluyver! |
|
Let's do it! |
|
👏👏👏 |
|
Nice addition @takluyver. Small issue with the merged PR: it broke the RTD build :( |
|
Thanks Carol. I think #2964 should fix it. |
|
Hello, I have deleted a Jupyter notebook by accident. I was using the Hub interface through google chrome, is there a way for me to recover this file? |
|
Hmm. Can you describe the environment (configuration, operating system, etc.) in which Hub is running? Do you have access to the machine which was/is hosting your spawned Notebook server instance? On Windows, I'm assuming the deleted file would reside in your In the meantime, I'm copying @minrk since he would have insight on how this might behave across a Hub cluster - either single or multi-node and might also have other ideas. I'm hoping your file is sitting in one of the aforementioned locations. Good luck. |
|
Hello, I don't have access to the server, it is the school's server, but it's okay tho, I just recoded the notebook. Thank you |
|
This should never have been merged as it results in unexpected behaviour. It causes only trouble for no benefits. Make this a separate menu entry "move to trash" and not disguise it as "delete". |
This adds a config option, defaulting to use trash, and adds a dependency on the pure-Python 'send2trash' package. Linux, Mac and Windows should all be supported.
Alternatively, we could make it default to hard delete (the current behaviour), and let users opt in to trash behaviour. Then Send2Trash could be a soft dependency.
This doesn't touch the UI yet, so you still get a confirmation dialog which inaccurately says it will permanently delete' the file. If we want to do this, we'll need some way for the contents manager to pass
the UI a hint about whether deleting is permanent or not.
Closes gh-165