all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: rms@gnu.org
Cc: johnw@newartisans.com,
	Lennart Borgman <lennart.borgman@gmail.com>,
	emacs-devel@gnu.org, schwab@linux-m68k.org, dave@boostpro.com,
	stephen@xemacs.org
Subject: Re: Proposed patch: allow user to disable lockfile creation
Date: Fri, 29 Jul 2011 10:12:11 +1000	[thread overview]
Message-ID: <CAC=50j-GXR-QNtn+W9Qp8f0nVJGmpZFJTxc3xMzxdxVDUH_XXQ@mail.gmail.com> (raw)
In-Reply-To: <E1QmZZG-0000We-2B@fencepost.gnu.org>

On Fri, Jul 29, 2011 at 9:00 AM, Richard Stallman <rms@gnu.org> 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	other threads:[~2011-07-29  0:12 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-27  2:42 Proposed patch: allow user to disable lockfile creation Dave Abrahams
2011-07-27 15:32 ` Andreas Schwab
2011-07-27 16:25   ` Dave Abrahams
2011-07-27 18:56     ` John Wiegley
2011-07-28  1:57       ` Stephen J. Turnbull
2011-07-28 16:46         ` Richard Stallman
2011-07-28 16:54           ` Lennart Borgman
2011-07-28 23:00             ` Richard Stallman
2011-07-29  0:12               ` Tim Cross [this message]
2011-07-29  0:51                 ` Dave Abrahams
2011-07-29 23:40                   ` Richard Stallman
2011-07-30  3:29                     ` Dave Abrahams
2011-07-30  7:21                       ` Eli Zaretskii
2011-07-30 12:32                         ` Dave Abrahams
2011-07-30 18:12                       ` Richard Stallman
2011-07-31  2:13                   ` Tim Cross
2011-07-29 23:40                 ` Richard Stallman
2011-07-30 12:46                   ` Dave Abrahams
2011-07-28 18:22           ` chad
2011-07-28 23:00             ` Richard Stallman
2011-07-28 19:21           ` Paul Eggert
2011-07-29 17:31             ` Richard Stallman
2011-07-29 19:59               ` David Kastrup
2011-07-30  4:35                 ` Richard Stallman
2011-07-30  7:36                   ` David Kastrup
2011-07-29  3:31           ` Stephen J. Turnbull
2011-07-28 21:20 ` Evil Boris
2011-07-30 14:20 ` Daniel Colascione
2011-07-30 18:12   ` Richard Stallman
2011-07-31  2:22     ` Tim Cross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAC=50j-GXR-QNtn+W9Qp8f0nVJGmpZFJTxc3xMzxdxVDUH_XXQ@mail.gmail.com' \
    --to=theophilusx@gmail.com \
    --cc=dave@boostpro.com \
    --cc=emacs-devel@gnu.org \
    --cc=johnw@newartisans.com \
    --cc=lennart.borgman@gmail.com \
    --cc=rms@gnu.org \
    --cc=schwab@linux-m68k.org \
    --cc=stephen@xemacs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.