root_dir for Contents Manager not loaded from config file

[krinsman]

I added the lines

c.ContentsManager.root_dir = '~'
c.FileContentsManager.root_dir = '~'

to ~/.jupyter/jupyter_notebook_config.py.

I then ran the Jupyter notebook server in debug mode, as follows (the setting of notebook_dir is deliberate):

jupyter lab --notebook-dir='/' --debug

EDIT: the exact same things happen when using the command

jupyter notebook --notebook-dir='/' --debug

and as far as I can tell, JupyterLab uses Notebook's contents manager anyway /EDIT
and it confirmed that the config file was loaded:

[D 16:50:53.349 LabApp] Loaded config file: ~/.jupyter/jupyter_notebook_config.py

My notebook server extension, which uses the .save method of the contents manager to save a notebook to the user's home directory (well in practice, to the root_dir of the contents manager), reports a 403 permissions error when trying to run, and in its log output (see code on GitHub) shows that the value of the contents manager's root directory is the value of notebook_dir, instead of the value specified in the config file.

[D 16:51:48.310 LabApp] Contents manager root_dir: /

This would be expected if no value of root_dir had been specified in the config file, since according to the code, the value of notebook_dir is to be loaded as the default if no value is specified in the configuration. However, a value was specified, and the value of root_dir is supposed to be configurable, so this seems to be a bug.

For further evidence that the value of root_dir specified in the config file is being ignored, I changed the config file to say

c.FileContentsManager.root_dir = 42

Because the value of root_dir is validated, if this configuration is being loaded, then a TraitError should be thrown as a result of this configuration setting. However, no errors are raised when starting the notebook server.

Random Thoughts:
All I can think of at the moment is that perhaps JupyterLab uses a different contents manager than the Jupyter notebook, maybe a subclass, and that for this reason the configuration is being effectively ignored? But I also changed the value of c.ContentsManager.root_dir in the config file, as well as c.LargeFileContentsManager.root_dir (since as far as I can tell the LargeFileContentsManager subclass of FileContentsManager is actually what's loaded/used), but it still does nothing. I initially thought that this was an issue with JupyterHub, but am now fairly convinced that this is not the case, especially since it's possible to reproduce the problem without running JupyterHub.

[krinsman]

Fixed by #5021