Re: File locking within zsh?

[Tim Writer <tim@xxxxxxxxxxx>]

"Brian K. White" <brian@xxxxxxxxx> writes:

> ----- Original Message ----- 
> From: "Tim Writer" <tim@xxxxxxxxxxx>
> To: "Lloyd Zusman" <ljz@xxxxxxxxxx>
> Cc: <zsh-users@xxxxxxxxxx>
> Sent: Tuesday, May 09, 2006 11:31 PM
> Subject: Re: File locking within zsh?
> 
> 
> > Lloyd Zusman <ljz@xxxxxxxxxx> writes:
> >
> >> Do any of you know of any functions, primitives, tricks, hacks, or even
> >> outright abominations which will allow me to do cooperative file locking
> >> from within zsh?
> >>
> >> I know that I can do this with a number of compiled executables, but I'm
> >> looking for a zsh-only solution.
> >>
> >> Assuming some sort of zsh locking operator called "lock", consider
> >> this example (within a zsh script):
> >>
> >>   lock -x -t 0 file  # for this example of a hypothetical operator, '-x'
> >>                      # means to wait until I get an exclusive lock, and
> >>                      # '-t 0' means no time out
> >>   print foo bar baz >>file
> >>   # do a whole lot of other stuff to "file"
> >>   unlock file # release the lock
> >>
> >> In this example, any other zsh script which asks for an exclusive lock
> >> on "file" using this hypothetical "lock" operator will block until the
> >> "unlock" operator has been invoked.
> >>
> >> Can this be done somehow in zsh, or do I have to rely on a compiled
> >> executable to accomplish this?
> >
> > The usual way to lock within shell scripts is to use ln. This works on all
> > UNIX like systems because creating a hard link (with ln) is an atomic
> > operation which fails if the target already exists. Your example above canbe
> 
> > written like this:
> >
> >    while ! ln file file.lock 2>/dev/null
> >    do
> >        sleep 1
> >    done
> >    # Lock obtained
> >
> >    print foo bar baz >>file
> >    # do a whole lot of other stuff to "file"
> >
> >    rm -f file.lock
> >    # Lock released
> >
> > Wrapping this idiom into lock/unlock functions is left as an exercise for the
> 
> > reader. :-)
> 
> 
> Is that better or worse, and why, than  umask 222 ; >file ?
> 
> http://www.unix.org.ua/orelly/unix/upt/ch45_36.htm

I think the ln solution is better because it's guaranteed to be atomic.
Granted, a sane implementation of ">file" will use open(2) with O_CREAT what
guarantees do you have that your shell (and I'm not talking about zsh here)
is sane? I have often seen code like this pseudocode:

    if (file exists)
        open file
    else {
        creat file
        open file
    }
  
I don't know that any shells contain crap like this but I don't know they
don't either.

-- 
tim writer <tim@xxxxxxxxxxx>                                  starnix inc.
647.722.5301                                      toronto, ontario, canada
http://www.starnix.com              professional linux services & products