It appears that send2trash assumes that os.rename can be used across filesystems, which is not true. It also appears that this probably isn't going to get fixed any time soon. (see https://github.com/arsenetar/send2trash/issues/26)
The _check_trash function seems to be trying to work around this, but the check it's using isn't generally valid (at least not on GPFS), preventing users from deleting files.
Possible solutions: remove send2trash entirely, or don't use it by default.
Is there a fix that would work on GPFS, or detect GPFS and disable it?
Perhaps have a temp copy, and only delete the copy if it was successfully copied to trash and otherwise refuse to delete it.
Removing it would be a terrible step backwards in those instances where it works.
Indeed, I get cross-device link yadda all the time from all kinds of libraries, even on relatively boring filesystems, but I'll agree with @dsblank that "has saved people from losing important work" is enough of a reason to keep it in.
Luckily, there is a FileContentsManager.delete_to_trash which you can specify in a json or py file, and this could even be hoisted to JUPYTER_DELETE_MY_FILES_FOREVER=1 if the config system doesn't work for your use case.
Thanks for replies. Don't think GPFS can easily be detected, but this is a fool's errand anyway, IMO. The only proper test for whether os.rename will work is to try it and observe any error codes. So, conceivably another path here would be to try the send2trash and if it fails, just hard delete the file.
Fundamentally, the use of a raw, unconditional os.rename by send2trash is simply wrong, especially in 2020.
I'm looking into the config setting, which I hope will work here. Thanks!
The config setting did indeed work for us. Thanks again!