A new error has occurred with a recent upgrade to Emacs 27.1. I'm trying to edit .gitignore and get the following error:

*ERROR*: Unlocking file: Invalid argument, <directory>/.gitignore

To check this is not an error in an initialisation file, I tried with emacs -q .gitignore. However, in this case the file is set to read-only and cannot be edited, and the strange error

File exists, but cannot be read

appears, then the file appears but as read-only. It doesn't seem to be possible to change to non-read only. To surmount this problem I have taken to renaming .gitignore to another file name then moving that using the mv command. The file itself is not read-only:

$ ls -l .gitignore
-rw-r--r--  1 ben  ben  843 Sep  4 07:20 .gitignore
  • 1
    I get the same error with emacs 27.1 on fc32. Also get it for a self-compiled emacs 28. – jamespo Sep 6 '20 at 21:52
  • 1
    Furthermore with a compiled version of 26.3 this doesn't occur – jamespo Sep 7 '20 at 9:12
  • I'm seeing the problem in only one directory and not in others where I try to edit .gitignore. – user23791 Sep 7 '20 at 10:30
  • Is this directory on a different type of filesystem than the others? There were changes in emacs-27 to the handling of file-system errors that might be responsible. – rpluim Oct 6 '20 at 8:35
  • @rpluim - no, the file system is the same. – user23791 Oct 7 '20 at 0:18

Does setting (setq create-lockfiles nil) in your configuration make the error go away? I ask because it appears to me that Emacs is getting the error when it tries to create or open or read from the lock file. The filename of the lock file will be .#.gitignore; you should investigate why it can't read or create this particular lock file while others work fine.

Chapter 18.3.4 Protection against Simultaneous Editing of the Emacs manual covers how Emacs uses the lock file.

  • 1
    There was a file called .#.gitignore in the directory which was an "unreadable symlink" according to the Unix file utility. Removing that made .gitignore editable. – user23791 Oct 7 '20 at 0:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy