Closed david-macmahon closed 3 years ago
Turns out using file:///readonlydir/notebook.jl
didn't work either. Seems not to be recognized as a URL and is instead treated as a relative path.
It would be quite a bit of work for us to make this work: we need to store the backup somewhere else, we need to store the notebook somewhere else after you edit and we need to communicate this behaviour to the user. Maybe later!
What about treating file:///...
URLs the same as http://...
URLs in terms of "copying" the notebook "locally" before opening? Is that worthy of a separate issue?
I get the same error for trying to opening a read-only file in a writable directory. I think it will be nice if Pluto was not complaining and just opening the notebook in a read only mode.
This way probably it would even be possible to open Pluto notebooks over the network e.g. http.
fyi, I tried opening the .julia/packages/Pluto/*/sample/Basic.jl
. Looks like Pkg downloads and saves the repository files as read-only.
Trying to open
/readonlydir/notebook.jl
where the user has no write permissions for/readonlydir
produces:I guess a backup in
/tmp
isn't really a backup, but maybe issuing a warning that no backup will be created or creating the backup under the users home directory (e.g. where notebooks are saved by default) would be better so that the notebook can still be opened? Or maybe it has to be copied to a writable directory before opening? It would be preferable to avoid being unable to open the notebook altogether just because it lives in a read-only directory.FWIW, copying from a read-only directory to a writable directory would provide a way to make "starter notebooks" that students could open and expand on. This is essentially what happens when opening a URL based notebook. I guess maybe a workaround is to use a
file://
URL, but it would still be nice to do this with a pathname too.