Brian E. Granger
Brian E. Granger
Marking this as beta - we might have time to do it and it is high value. Can be deferred if needed.
We could also create a `jupyter mv` command that allows users to update the database entry if they move/rename files out of band.
Great point @jasongrout - do you think we could implement some git hooks that manage all that?
@davidbrochart I would probably keep the id service to just handling the ids, and let other services provide additional capabilities on top of that (like versioning). @dhirschfeld You are right...
@echarles thanks for your comments and questions. A few follow ups... * Optional? There are extensions such as commenting, RTC, notebook sharing (https://github.com/jupyterhub/hubshare) that require this capability. We can make...
I agree that indexing all the files under the users Jupiter server root might be a performance issue. What if we took the same approach that git takes and allowed...
* It is my understanding that `inotify` is not supported on common file systems used by Jupyter users (such as NFS/EFS). I don't think there is any problem to having...
Hi Vidar, great question. Originally, that was how we were thinking, but we found that the file ID manager needed more access to and integration with the content manager for...
Kevin, thanks for describing the scenarios. We have also been talking about a command line program that provides additional capabilities related to working with these ids and related data (comments,...
Closing as implementation is completed in: https://github.com/jupyter-server/jupyter_server_fileid