Resource hash in filename if copy/open/downloading file in root dir

[jeflem]

If a jupyter-fs file browser (for a local file system, osfs://) is used for copying, opening or downloading a file which is not in a subfolder, then the filename will contain the resource hash:

• copy: destination file name will be hash:filename (jupyter-fs will show two files with identical names, but terminal knows the truth)
• open: tab title in JupyterLab will be hash:filename
• download: webbrowser's suggested filename for saving will be hash_filename (Firefox)

For files in subdirectories everything works as expected.

To Reproduce
Steps to reproduce the behavior:

1. Configure osfs:// resource for jupyter-fs.
2. Navigate to the highest level (root).
3. In the file browser double click a file.
4. Look at the editor's tab title.

or
3. right-click a file, then copy, then paste

or
3. right-click a file, then download

Expected behavior
Resource hash shouldn't appear in the GUI. Especially for copying, destination filename should be filename-Copy-1 or the like.

Desktop (please complete the following information):
tested on Debian 12 with Firefox 115.14 and

• JupyterLab 4.0.11
• jupyter-fs main branch

Additional context
For copying jupyter-fs calls Jupyter Server's AsyncContentsManager.copy. There the source path is tested for containing /. If there's no / then the whole path (including resource hash) is considered as filename, causing the troubles.

A (hacky) workaround is to modify jupyter-fs' _resolve_path in pathutils.py to prepend ./ to every path not containing /. Then every path contains / and splitting at the last / to get the filename yields a valid directory path (including the resource hash) and the correct filename. This seems to solve the problem for copy and download, but not for open.

[jeflem]

Same problem with webdav:// resources. And also with current JupyterLab 4.2.4