This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: keychain locking problem (Was test -f occasionally fails on sym links)

On Mar 29 06:47, Karl M wrote:
> The reason I ask is that keychain uses
>    if tl_error=`ln -s $$ "$lockf" 2>&1`; then
> inside its takelock function as an atomic operation for creating a lock. It 
> then uses
>    if [ -f "$lockf" ]; then
> to test for an old style lock file, and this sometimes fails (incorrectly 
> succeeds) and generates an error message.
> >From what I can find, this is expected to be an atomic operation and one 
> >of 
> the ways programs do file locking.

No chance.  Cygwin is not the OS and the OS doesn't support native symlinks
and consequentially no atomic symlink creation.

>    if (umask 0377; : > ~/.keychain/${HOSTNAME}-keys) 2>/dev/null; then
>      keychain --quiet ~/.ssh/identity ~/.ssh/id_dsa ~/.ssh/id_rsa
>    fi
> and the lock file is cleaned up by the keychain-service. This does seem to 
> be safe (only verified by load testing under Cygwin). I found this method 
> in the UNIX CD Bookshelf.
> questions are
> 1) Is this a safe method?

Yes, AFAICS.  File creation and setting of permissions is atomic, as
long as you don't rely on "ntea".  But that's old stuff, just ignore it.

> 3) Should this problem be fed to the upstream keychain maintainer?

The symlink creation problem?  If the upstream maintainer cares, sure.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader
Red Hat, Inc.

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]