1

On Mac OS Big Sur (11.6.3) with nvi 1.81.6 and several tmux panels, I accidentally quit Terminal.

Now opening files leads to the message

<file> already locked, session is read-only
<file> unmodified, readonly: line 1

After consulting this answer about recovery files, I was a little confused about the files in /var/tmp/vi.recover/ directory.

The recover.XXXXX files appear to be plaintext emails starting with two special headers,

  • X-vi-recover-file and
  • X-vi-recover-path

The second header value points to a path like /var/tmp/vi.recover/vi.YYYYY, which can be either a file or directory.

When it is a file, it is binary. When it is a directory, it is empty.

After creating a copy of the recover.XXXXX file, and seeing it was pointing to "correct" paths already, it was not clear what to update the values to. Using nvi -r <file> just outputs

No files named <file>, readable by you, to recover.

Anyway, I removed all the recover.* files and vi.*/ folders, and nvi still opens the file read-only.

Is there a permanent solution, where I do not have to use :set noro each time I edit the file?

6
  • perhaps try :set nolock?
    – D. Ben Knoble
    Commented Mar 1, 2022 at 14:35
  • @D.BenKnoble Thank-you. After adding set nolock to the nvi startup file ~/.nexrc, the read-only issue is resolved. However, a nice "feature" of the read-only warning is knowing the file is opened already (in another tmux panel or new Terminal tab). The question originally did not mention this, so I'll update to provide more context. Commented Mar 1, 2022 at 14:58
  • Note that answers really belong below, in the answer section, and not in the Question. Another thing to try: find out if any processes are still using the file (e.g., via lsof)
    – D. Ben Knoble
    Commented Mar 1, 2022 at 15:00
  • @D.BenKnoble Thank-you for that. Running lsof <file> does show one entry, and it is for nvi. I have no visible editing sessions for the file; maybe this is running in the tmux session from before I quit Terminal? I can check for that. In the meantime, should I make the workarounds above separate Answers? Commented Mar 1, 2022 at 15:05
  • 1
    Separate answers added. I can mark the tmux kill-session -a post as the Answer in a bit, unless otherwise suggested. Thank-you again @D.BenKnoble. Commented Mar 1, 2022 at 15:26

5 Answers 5

0

Disable read-only with :set noro.

Using :w will now let you save as normal, at least until the next time you edit the file.

0

If the file is opened read-only, you can force overwrite the file each time with :w!

Be careful, as this may invalidate other instances of the file opened in other editing sessions. Saving in those sessions may overwrite previous changes in the window where you used :w!

0

Add set nolock to the nvi startup file ~/.nexrc to always disable read-only warnings.

Per comment from @D.BenKnoble

0

You may have a lingering tmux session that has an nvi editing session locked to that file.

You can verify this with lsof <file> to determine which process still has a reference to the file.

In this case,

  • tmux ls to list all windows
  • tmux kill-session -a to exit all windows except current

After exiting all windows except the current one (which does not have the read-only file open), nvi <file> did not warn about read-only as desired.

Thanks to @DBen.Knoble for helping me down this trail.

0

The following worked for me after suggestions above failed:

mv filename some-other-dir
cp some-other-dir/filename .

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.