Read-only notebooks can't be unlocked for editing

[ivan-kalev]

Read-only notebook files remain read-only even if the read-only file system flag is cleared. Restarting the kernel doesn't help. The only option at the moment is to close the notebook and open it again, potentially losing all changes. Maybe IPython could check if the current notebook is read-only every time the save button is pressed, rather than only once immediately after loading the file?

Steps to reproduce:

1. Create a new notebook file
2. Make the file read-only
3. Open the notebook -- IPython properly detects that the notebook is read-only
4. Clear the read-only flag of the notebook file
5. Attempt to save the notebook - IPython still reports that the file is read-only

Tested on windows with IPython 3.0.0. I think this problem didn't exist in earlier versions.

[minrk]

I think you will need to reload the page.

[Carreau]

We discussed that already in person I dont' remember all the details, but propagating the change of the on-disk file is problematic in a few ways. 1) you have to watch the files regularly. 2) lots of logics are not triggered/deactivated when the file is RO (autosave is one of them). 3) if we support making file writable again, then we need to support setting the file a RO while the notebook is loaded.

Checking only at save, also mean we dont' get early warning as current UI does.

So maybe we should make it more visible when you start modifying things, that the notebook is RO.

[ivan-kalev]

You are aleady doing a pretty good job at making it visible. It's quite nice. The problem is that people intuitively assume that the read-only state is reversible and start editing anyway.

I think the ideal solution would be to keep the existing implementation, but also re-check permissions on any manual attempt to save (clicking the save button or hitting ctrl-s). Another good alternative would be to offer a Save As functionality, so users would have a chance to save their work and manually overwrite the locked file later.

[Carreau]

The "Save As" option is weird because you are backed by a kernels, and what do you do ? Create a new kernel ? You can't have 2 notebooks attached to the same kernel.

There is a make a copy, but make a copy also rely on having disk access...

It's internally more complex than it looks, but we'll try to do better.

[ivan-kalev]

Yeah, I presume you could create a brand new notebook with a different name? Exactly what "Make a copy" does, except that all changes are lost in the current implementation.

[donnemartin]

It would be great to have a fix for this.

I run into this issue quite often when I work with notebooks in a source control system that locks your local files that that aren't checked out (for example, Perforce).

Sample use case:

• Start working with a notebook, not realizing I haven't checked it out with Perforce.
• Make changes and hit save, realize the notebook is read-only.
• Check out the notebook in Perforce, which removes the read-only lock.
• Go back to Notebook and try to save, no luck, notebook is still showing as 'locked'.

[jonmoore]

Actually the current early warning is too subtle given that users may lose work and will certainly be concerned - it's quite easy for someone to start editing without realizing that the backing file is readonly. A modal dialog (or something else requiring agreement) once a user tries to edit would be better.

[PrinterOperator]

An alternative to begin able to make changes and adding a Save As feature, would be to not allow changes to a read-only file. Only allow cell execution.

[takluyver]

Discussion continues on jupyter/notebook#1324 - thanks @PrinterOperator for resurrecting it.

[stringhamc]

The problem with the "make a copy" workaround is that it copies the notebook on disk not the one in memory. So any changes that have been made will be lost.

[amedlin]

Wow, I just lost half an hour's work due to this! I didn't notice it was read-only, and "Make a Copy" didn't work "Save and checkpoint" was disabled because it was read-only, and there is no "Save as..." feature.

This is really not user-friendly!

[legalsmeagol15]

Wow I just lost six hours' work. Never noticed the tiny little icon indicating RO and save is locked - I even told it to save a couple of times and didn't notice the other tiny little icon complaining it was RO status. I am more than a little miffed. Surely the notebook could provide better notice of RO status.

[walkerh]

After being burned by this many times I discovered this workaround hack from this thread:

jupyter/notebook#1324 (comment)

1. Make sure your notebook file on disk is writeable.
2. Open the debugger for your browser.
3. Search for: Notebook.prototype.save_notebook
4. Set a breakpoint just inside that function.
5. Click the save icon. (The debugger will halt at your breakpoint.)
6. Enter the javascript console.
7. Execute this code: this.writable = true
8. Resume execution of the debugger.

It saved my file! For once I didn't lose content!

This is an ugly hack, but its better than the alternative.

[den-run-ai]

I found an easy workaround:

1. Select all cells in command mode (Ctrl and Down).
2. Ctrl+C to copy all cells.
3. Open new notebook.
4. Ctrl+V to paste the copied cells.

This seems to be copying even cell outputs.

[YangZhou0417]

For me, chmod 777 <notebook_directory> on linux solve the issue.

[PedroGFonseca]

It would seem that one can now go into the metadata and alter the cells.

Going to view, cell toolbar, edit metadata

And then changing the deletable and editable to true