bug#43535: File locking on Windows

bug#43535: File locking on Windows

[Richard Copley]

Recipe from "emacs -Q", on Windows:

Visit a file "x.cpp". Modify the buffer and don't save.

    M-! clang-format -i *.cpp RET

This has the effect of altering the contents of the lock file
".#x.cpp". Most Windows programs that accept wildcards and edit files
in place will do the same, since they don't usually skip dot files.
Now we are in a pickle:

    M-x revert-buffer RET
    yes RET

Error:  Unlocking file: Invalid argument, c:/x.cpp

    C-x k RET
    yes RET

Error: Unlocking file: Invalid argument, c:/x.cpp

    C-x C-c
    n
    yes RET

Emacs doesn't close or print an error but becomes unusable, having
apparently deleted all windows. You can still use the minibuffer.
Delete the lock file and kill Emacs:

    M-! del .#x RET
    C-x C-c
    n
    yes RET

This is quite a cruel punishment for an understandable mistake. I
assume it started happening when Paul fixed the error handling in
"filelock.c". It happens on master and Emacs 27.2, and not on Emacs
26.3.

There is more than one conceivable way to avoid this. E.g., use a
different lock file name, keep the lock file open in deny-share mode
to prevent accidents, ignore certain errors while unlocking. In fact
I'd like to have an option to permanently disable creating lock files.

bug#43535: File locking on Windows

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Sun, 20 Sep 2020 16:54:56 +0100
> 
> I'd like to have an option to permanently disable creating lock files.

I think you should be able to do that by customizing the variable
create-lockfiles.

bug#43535: File locking on Windows

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Sun, 20 Sep 2020 16:54:56 +0100
> 
> This is quite a cruel punishment for an understandable mistake. I
> assume it started happening when Paul fixed the error handling in
> "filelock.c". It happens on master and Emacs 27.2, and not on Emacs
> 26.3.
> 
> There is more than one conceivable way to avoid this. E.g., use a
> different lock file name, keep the lock file open in deny-share mode
> to prevent accidents, ignore certain errors while unlocking.

I think ignoring errors, perhaps after asking for confirmation, is the
only way.  Using a different file name will just move the problem
elsewhere, and keeping the file open will disallow stealing the lock,
and on MS-Windows will have other annoying effects (like keeping the
file's directory busy etc.).

bug#43535: File locking on Windows

[Richard Copley]

Eli Zaretskii wrote:
> > I'd like to have an option to permanently disable creating lock files.
> I think you should be able to do that by customizing the variable
> create-lockfiles.

Thanks.

> I think ignoring errors, perhaps after asking for confirmation, is the
> only way.  Using a different file name will just move the problem
> elsewhere, and keeping the file open will disallow stealing the lock,
> and on MS-Windows will have other annoying effects (like keeping the
> file's directory busy etc.).

Right.
Parse failure in "current_lock_owner" isn't handled well. You can
force the same issues to occur on a non-Windows system by deleting the
".#x" symlink and recreating it with a bad target.

bug#43535: File locking on Windows

[Lars Ingebrigtsen]

Richard Copley <rcopley@gmail.com> writes:

> Parse failure in "current_lock_owner" isn't handled well. You can
> force the same issues to occur on a non-Windows system by deleting the
> ".#x" symlink and recreating it with a bad target.

I tried reproducing this in Debian:

cd tmp
touch foo
ln -s noexist .#foo

and then editing and saving /tmp/foo:

Warning (unlock-file): Unlocking file: Invalid argument, /tmp/foo, ignored

So a warning pops up here...  which I think is reasonable?

Do you see something different?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#43535: File locking on Windows

[Richard Copley]

Lars wrote:

> Do you see something different?

No. Looks like this was fixed collateral to
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46397>.

Thanks.

bug#43535: File locking on Windows

[Lars Ingebrigtsen]

Richard Copley <rcopley@gmail.com> writes:

>> Do you see something different?
>
> No. Looks like this was fixed collateral to
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46397>.

OK; good.  But does this mean that the reported bug on Windows is also
gone?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#43535: File locking on Windows

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Richard Copley <rcopley@gmail.com> writes:
>
>>> Do you see something different?
>>
>> No. Looks like this was fixed collateral to
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46397>.
>
> OK; good.  But does this mean that the reported bug on Windows is also
> gone?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no