send2trash
send2trash copied to clipboard
Deleting file fails
After trying to delete a file with send2trash
via the Jupyter Notebook, it appears that send2trash
tries to create a directory within the file. Thus giving us the traceback below.
Traceback (most recent call last):
File "/opt/conda3/lib/python3.6/site-packages/tornado/web.py", line 1543, in _execute result = yield result
File "/opt/conda3/lib/python3.6/site-packages/tornado/gen.py", line 1099, in run value = future.result()
File "/opt/conda3/lib/python3.6/site-packages/tornado/gen.py", line 315, in wrapper yielded = next(result)
File "/opt/conda3/lib/python3.6/site-packages/notebook/services/contents/handlers.py", line 235, in delete yield gen.maybe_future(cm.delete(path))
File "/opt/conda3/lib/python3.6/site-packages/notebook/services/contents/manager.py", line 278, in delete self.delete_file(path)
File "/opt/conda3/lib/python3.6/site-packages/notebook/services/contents/filemanager.py", line 499, in delete_file send2trash(os_path)
File "/opt/conda3/lib/python3.6/site-packages/send2trash/plat_other.py", line 191, in send2trash dest_trash = find_ext_volume_trash(topdir)
File "/opt/conda3/lib/python3.6/site-packages/send2trash/plat_other.py", line 151, in find_ext_volume_trash trash_dir = find_ext_volume_fallback_trash(volume_root)
File "/opt/conda3/lib/python3.6/site-packages/send2trash/plat_other.py", line 141, in find_ext_volume_fallback_trash check_create(trash_dir)
File "/opt/conda3/lib/python3.6/site-packages/send2trash/plat_other.py", line 86, in check_create os.makedirs(dir, 0o700)
File "/opt/conda3/lib/python3.6/os.py", line 220, in makedirs mkdir(name, mode) NotADirectoryError: [Errno 20]
Not a directory: b'/nanshe_workflow/data.tif/.Trash-0'
I think we ran across something like this before. Are you running Jupyter in some kind of container?
My memory of it is fuzzy, but if I recall correctly, the stat
calls were giving a different device (st_dev
) for the file and the directory it's in. send2trash finds the mount point by walking up the path and looking for when a parent directory is on a different device, so in this situation it's detecting the file itself as the mount point, and trying to create the trash directory under there.
send2trash may be able to protect against this by starting the search one level up (even if you're trashing a folder, you can't trash it into itself). But I don't know if that will put the trash anywhere useful for restoring/emptying it. You can configure Jupyter to really delete files (with no trash) using the option FileContentsManager.delete_to_trash = False
.
Yeah this is in a container. The directory in question is mounted.
Thank you, FileContentsManager.delete_to_trash = False
resolved the issue on RunPod containers for me, much appreciated 👍 .