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:
Configure osfs:// resource for jupyter-fs.
Navigate to the highest level (root).
In the file browser double click a file.
Look at the editor's tab title.
or
right-click a file, then copy, then paste
or
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.
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:hash:filename
(jupyter-fs will show two files with identical names, but terminal knows the truth)hash:filename
hash_filename
(Firefox)For files in subdirectories everything works as expected.
To Reproduce Steps to reproduce the behavior:
osfs://
resource for jupyter-fs.or
or
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
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
inpathutils.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.