[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Locking files for CLASH_DETECTION now supported on MS-Windows
From: |
Paul Eggert |
Subject: |
Re: Locking files for CLASH_DETECTION now supported on MS-Windows |
Date: |
Tue, 26 Feb 2013 23:45:38 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 |
>>> We could avoid this by teaching Emacs on Posix systems to
>>> read lock files created by Emacs running on Windows.
>>
>> I don't see how to do this without introducing race
>> conditions that are not present in the current GNU/Linux
>> implementation.
>
> Can you describe those race conditions? I'm talking only about
> _reading_ those files, not about creating them.
Sorry, I must have misunderstood you.
There are no races if access is read-only. We need at least one
writer (i.e., one process that's either creating or removing a
lock file) in order to have a race. I thought the original
scenario involved an MS-Windows Emacs locking a file at about
the same time that a GNU/Linux Emacs locks the same file.
> The changes you are promoting cause Emacs to take control of any
> file whose name matches the pattern .#FILE, where FILE is the file we edit.
No, under that proposal, if there's an existing non-symlink
.#FILE then Emacs doesn't lock FILE; it simply bypasses
locking for FILE for entirely and it doesn't modify .#FILE
at all. This should be relatively rare.
It is true that if there's an existing symlink .#FILE then Emacs
will take control of it when it edits FILE, but that should be OK.
>>> Another possibility would be to make Emacs running on Windows avoid
>>> locking files on remote filesystems.
>>
>> Won't there still be a problem if the local file system is
>> exported?
>
> No, because such exported systems will not support symlinks from Posix
> hosts.
I thought that such symlinks were supported: the lock would appear to be a
regular file
on the MS-Windows server side, but as exported over the network it would
appear to be a symbolic link on the GNU/Linux client side, as that's
how the Microsoft server software works. If the MS-Windows
and GNU/Linux locks have the same name, they'd collide
I presume.
>> To move things forward, I propose that the MS-Windows
>> implementation use a different lock file name .#-FOO.
>
> I don't mind, but I thought we could do better.
It's possible that we can do better, but I'm afraid that'll
take some work. In the meantime I plan to go ahead with that
proposal as it's better than what we have now.
- Re: Locking files for CLASH_DETECTION now supported on MS-Windows, (continued)
- Re: Locking files for CLASH_DETECTION now supported on MS-Windows, Eli Zaretskii, 2013/02/25
- Re: Locking files for CLASH_DETECTION now supported on MS-Windows, Paul Eggert, 2013/02/26
- Re: Locking files for CLASH_DETECTION now supported on MS-Windows, Eli Zaretskii, 2013/02/26
- Re: Locking files for CLASH_DETECTION now supported on MS-Windows, Eli Zaretskii, 2013/02/26
- Re: Locking files for CLASH_DETECTION now supported on MS-Windows, Paul Eggert, 2013/02/26
- Re: Locking files for CLASH_DETECTION now supported on MS-Windows, Eli Zaretskii, 2013/02/26
- Re: Locking files for CLASH_DETECTION now supported on MS-Windows,
Paul Eggert <=
- Re: Locking files for CLASH_DETECTION now supported on MS-Windows, Eli Zaretskii, 2013/02/27
- Re: Locking files for CLASH_DETECTION now supported on MS-Windows, Eli Zaretskii, 2013/02/27
Re: Locking files for CLASH_DETECTION now supported on MS-Windows, Stefan Monnier, 2013/02/25
Re: Locking files for CLASH_DETECTION now supported on MS-Windows, Eli Zaretskii, 2013/02/25