Re: Unable to read history on latest Cygwin

Re: Unable to read history on latest Cygwin

[Peter A. Castro]

On Thu, 17 Dec 2009, Wayne Davison wrote:

[appologies for cross-posting to both lists.  I wanted to ensure this
thread carried over to zsh-workers where PeterS. moved it to, if there
are future discussions.]

> On Thu, Dec 17, 2009 at 12:04 AM, Peter A. Castro <doctor@fruitbat.org>wrote:
>
>> Hmm...atomic in the sense that the open vectors through the symlink to the
>> real file?
>>
>
> No, atomic as in no two people can think they were successful in creating it
> -- one must succeed, and everyone else must fail.  A file created
> *without*O_EXCL succeeds for everyone, but sadly, O_EXCL does not always work
> correctly (e.g. older NFS don't always support it). Thus, what matters is if
> the chosen idiom can safely be used as a single-success locking method or
> not.  For O_EXCL, cygwin just needs to have implemented that right.  For
> symlinks, it will depend on how the creating of the (symlink-emulating) file
> is created in the cygwin code.

Ah, I understand.  Cygwin relies on the underlying mechanisms available
from MS Windows file API.  From reviewing Cygwin code, it appears it is
using the native support for exclusive file locking, so, I beleve that,
yes, it does what you want (ie: only one process can exclusively open a
file using O_EXCL).

Creating symlinks, however, may not be atomic.  I'll have to check code
on that, but the symlink is really just an ordinary file.  I'll have to
check weither it's created with exclusive locks or not.

> ..wayne..

-- 
Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com>
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: Unable to read history on latest Cygwin

[Peter Stephenson]

On Thu, 17 Dec 2009 12:00:25 -0800
Wayne Davison <wayned@users.sourceforge.net> wrote:
> On Wed, Dec 16, 2009 at 7:54 AM, Wayne Davison <4wayned@gmail.com> wrote:
> 
> > According to various web docs, symlinks are atomic on NFS, so that might be
> > a good thing to use in general (replacing the use of link()).
> >
> 
> Attached is my patch for adding preferential use of a symlink as the locking
> mechanism.  This should interoperate just fine with a hard-link creating
> locker, but sadly, will have issues if another locker is using open with
> O_EXCL.  I've made the symlink name "/pid-$PID/host-$HOST" in an attempt to
> make a create (open) over an existing symlink fail with an error (unless the
> /pid-$PID dir happens to exist and is writable).  We could try to add
> O_NOFOLLOW (when available) to the O_EXCL-open as well.  However, hopefully
> no system will exist where one zsh locker is trying to use open-locking and
> another is trying to use a link-locking idiom.
> 
> What do you think?  Dangerous?  Useful?

(I moved this to zsh-workers.)

What about the historical behaviour of zsh?  Are there old versions of the
shell that might do something inconsistent with this?  This is not a
typical problem for most users, anyway, but it would be good not to stir
things up unnecessarily.

Other than that I can't think of any aspect that looks particularly
dangerous.  We could limit this to both HAVE_LINK and HAVE_SYMLINK to
ensure it didn't change the behaviour on systems without link()---slightly
illogical but unlikely to be a real limitation on the most common systems.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom