emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed patch: allow user to disable lockfile creation


From: Tim Cross
Subject: Re: Proposed patch: allow user to disable lockfile creation
Date: Fri, 29 Jul 2011 10:12:11 +1000

On Fri, Jul 29, 2011 at 9:00 AM, Richard Stallman <address@hidden> wrote:
>    Is not the default today to have single users machines? And in other
>    cases have accounts setups so that clashes will not occur.
>
> Most machines today are single users, but I don't follow the second
> part.  What do you mean by "account setups"?
>
> Normally, in a multi-user machine, people cooperate and there are some
> files that various people might edit.
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>  Use free telephony http://directory.fsf.org/category/tel/
>
>

Another common use case is single systems with multiple serial users
i.e. there is only ever one person actively using the system, but it
is used by multiple people. In the 'old days' you would have to log
out to allow another person to log in (via the same keyboard/monitor
etc). However, many systems now have a 'switch user' context, which
allows the desktop to switch to another user without the previous use
logging out. Potentially, this could have locking implications.

Yes, as far as I know, most of the remote file systems do have an
entry in the output of df, at least under GNU Linux. Another common
remote filesystem is sshfs, which uses the fuse utilities with ssh and
can be dynamically created by the user. While most remote filesystems
can are listed in df, not all of them have entries in fstab and the
list is or can be somewhat dynamic i.e. change during a user's
session.

It seems that the issue isn't really about conflict detection per se,
but rather how emacs implements it via symlinks. If the OS level file
locking has matured enough, it would certainly be something worth
looking at as I imagine it will allow emacs to perform such protection
'privately' and not put things in the filesystem which can impact on
other programs.  Personally, I've not found this an issue as the
symlinks that emacs uses are easy to recognize and most of the scripts
I use are ones I've written and told to ignore such links/directories.

Tim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]