"save file as" tries relative path even after entering leading '/'/Jupyter ignores it when "save file as" fails

[jd41]

• when entering an absolute path (with leading '/') in the "save file as" dialog, the thing still tries to save based on relative path. EDIT: Jason's reply states that Jupyter considers "absolute paths" relative to a root path. The only UX suggestion I see now is to add this remark to the UX ("path is relative to $ROOT_PATH") when someone clicks "save file as" etc. When using the server for the first time, it wasn't really transparent to me.

• After clicking "save file as", entering a path, and this failing e.g. due to having specified a non-existent folder, I nevertheless see the new path+name when clicking on "rename file".

Tried with an md file, "save file as" failed because of "no such file or directory" in my case (which in turn was the case because it tried a path relative to my home directory, even though I intended a leading '/' with my path).

OS: Linux

conda list|grep jupy
1.0.0 py_2 conda-forge
jupyter_client 6.1.5 py_0 conda-forge
jupyter_console 6.1.0 py_1 conda-forge
jupyter_contrib_core 0.3.3 py_2 conda-forge
jupyter_contrib_nbextensions 0.5.1 py36h9f0ad1d_1 conda-forge
jupyter_core 4.6.3 py36h9f0ad1d_1 conda-forge
jupyter_highlight_selected_word 0.2.0 py36h9f0ad1d_1002 conda-forge
jupyter_latex_envs 1.4.6 py36h9f0ad1d_1001 conda-forge
jupyter_nbextensions_configurator 0.4.1 py36h9f0ad1d_2 conda-forge
jupyterlab 2.2.8 py_0 conda-forge
jupyterlab_server 1.2.0 py_0 conda-forge

• Browser and version: Firefox 80

[jd41]

[W 14:51:44.112 LabApp] Unexpected error while saving file: nonex/untitled.md [Errno 2] No such file or directory: '/home/kubuntu/nonex/untitled.md'
[E 14:51:44.114 LabApp] {
"Host": "localhost:5000",
"User-Agent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0",
"Accept": "/",
"Accept-Language": "en-US,en;q=0.5",
"Accept-Encoding": "gzip, deflate",
"Referer": "http://localhost:5000/lab?",
"Content-Type": "text/plain;charset=UTF-8",
"X-Xsrftoken": "2|a491a167|2ee3b6c4c8be1d737e1b5dd28f587e38|1602850832",
"Origin": "http://localhost:5000",
"Content-Length": "75",
"Dnt": "1",
"Connection": "keep-alive",
"Cookie": "username-localhost-5000="2|1:0|10:1601915442|23:username-localhost-5000|44:NWJmMzkxNWU4NDg5NDI3ZmEyMzE3NDYwMzgwMDdmODI=|c7bedec7ed26c4ae902d7e8910d3e4afee67741e233bdb3179751c8f2668b464"; _xsrf=2|a491a167|2ee3b6c4c8be1d737e1b5dd28f587e38|1602850832",
"Pragma": "no-cache",
"Cache-Control": "no-cache"
}

[jasongrout]

All paths from the Lab UX are relative to the root directory JLab has (usually the directory JLab was started in, but it can also be set when launching JLab). This is a security decision in the server, not in JupyterLab itself.

[jd41]

Thanks for the quick answer @jasongrout.

From my UX perspective: When a user enters an absolute path (leading '/'), or path starting with '../' etc., I would still prefer interpreting it as an absolute path and checking whether it is permitted - or at least an error message outputting the root path - to silently cutting out the leading '/'. I appended this to the original issue.

[jasongrout]

Jupyter server has taken the convention from webservers that the server specifies the root directory, and absolute paths refer to that root directory. If you want your server root directory to be the same as the root directory of the computer, you can start JupyterLab in the root directory of your server, or you can set the root directory explicitly when launching using --notebook-dir=/ or --ServerApp.root_dir=/.

[jd41]

Alright, I didn't know that, the only UX suggestion I see now is to add this remark to the UX ("path is relative to $ROOT_PATH" or adding the root path as a text to the left of the path input field) when someone clicks "save file as" etc. When using the server for the first time, it wasn't really transparent to me. The UI also seems to be somewhat inconsistent to me: When I click "rename", Jupyter prints the absolute path of the file without any split into root and relative path.

[jasongrout]

When I click rename in the File menu, I see the path relative to the server root:

[jd41]

I am sorry, writing "absolute path" was not correct. The thing seems to be that when I hit "save as", the relative path I am entering is not validated, and a leading /, /.. / etc. aren't removed. In contrast, when I click "rename file", the input is validated (it tells me it is not allowed to contain '/').

Clicking "rename" after "Save File As" to "/////test":

Trying a non-existent path '/nonex/test':


("no such file or directory" includes the full OS absolute path here)

Saving at '../../test' gives a different error:


After clicking "rename file" again:

from the log:
[W 13:51:31.937 LabApp] 404 GET /test?1603399891710 (127.0.0.1) 211.70ms referer=http://localhost:5000/lab?
[W 13:51:32.035 LabApp] 404 GET /test?content=0&1603399892011 (127.0.0.1) 4.95ms referer=http://localhost:5000/lab?
[W 13:51:32.135 LabApp] 404 PUT /test?1603399892106 (127.0.0.1) 5.12ms referer=http://localhost:5000/lab?

I insist that, apart from these issues with "Save as", the UX is not as clear as it could be about the root paths (see edit in first issue message for a suggestion). I also see some suboptimality with the current solution that "Rename file" disallows slashes altogether, and the current path is shown above the input field: If the absolute root path was shown as a text on the left side, and the full relative path in an editable box on the right, the root-path thing would be clearer to new users and they would have an easy option to change filename+path at once (which I as a new user at least didn't find until now - only "Save as", which keeps the original file IIUC).

[Carreau]

As there was another issue opened recently pointing to this I want to add one other note:

For many users of JupyterHub of other Jupyter deployment the "relative to $ROOT_PATH" make no sens as they have no other way to access the filesystem above $ROOT_PATH, those users may not even be on a filesystem.

You are on a specific case where both the server and kernels are on the same filesystem, and you are not chrooted in $ROOT_PATH, so you see it.

It is not optimal as many user use notebook locally, but leaking absolute path through a layer of abstraction which is ment to hide filesystem seem like a recipe to create more problem than it solves.