* bug#43535: File locking on Windows
@ 2020-09-20 15:54 Richard Copley
2020-09-20 16:03 ` Eli Zaretskii
2020-09-20 16:14 ` Eli Zaretskii
0 siblings, 2 replies; 8+ messages in thread
From: Richard Copley @ 2020-09-20 15:54 UTC (permalink / raw)
To: 43535
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.
^ permalink raw reply [flat|nested] 8+ messages in thread* bug#43535: File locking on Windows
2020-09-20 15:54 bug#43535: File locking on Windows Richard Copley
@ 2020-09-20 16:03 ` Eli Zaretskii
2020-09-20 16:14 ` Eli Zaretskii
1 sibling, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2020-09-20 16:03 UTC (permalink / raw)
To: Richard Copley; +Cc: 43535
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#43535: File locking on Windows
2020-09-20 15:54 bug#43535: File locking on Windows Richard Copley
2020-09-20 16:03 ` Eli Zaretskii
@ 2020-09-20 16:14 ` Eli Zaretskii
2020-09-20 17:32 ` Richard Copley
1 sibling, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2020-09-20 16:14 UTC (permalink / raw)
To: Richard Copley; +Cc: 43535
> 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.).
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#43535: File locking on Windows
2020-09-20 16:14 ` Eli Zaretskii
@ 2020-09-20 17:32 ` Richard Copley
2021-07-31 13:05 ` Lars Ingebrigtsen
0 siblings, 1 reply; 8+ messages in thread
From: Richard Copley @ 2020-09-20 17:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 43535
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#43535: File locking on Windows
2020-09-20 17:32 ` Richard Copley
@ 2021-07-31 13:05 ` Lars Ingebrigtsen
2021-07-31 13:36 ` Richard Copley
0 siblings, 1 reply; 8+ messages in thread
From: Lars Ingebrigtsen @ 2021-07-31 13:05 UTC (permalink / raw)
To: Richard Copley; +Cc: 43535
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-08-29 20:17 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-20 15:54 bug#43535: File locking on Windows Richard Copley
2020-09-20 16:03 ` Eli Zaretskii
2020-09-20 16:14 ` Eli Zaretskii
2020-09-20 17:32 ` Richard Copley
2021-07-31 13:05 ` Lars Ingebrigtsen
2021-07-31 13:36 ` Richard Copley
2021-07-31 14:15 ` Lars Ingebrigtsen
2021-08-29 20:17 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).