> (note that F_GETLK man page does not provide EAGAIN as a
     > possible error code).
Hmm....
In the Single UNIX spec, there appears to be a rather unexpected
difference between expected behaviour for lockf and fcntl here:
http://www.db.opengroup.org/cgi-bin/dbcgi?CALLER=sud2/indx.tpl&TOKEN=FIYR&TPL=sd_fileframe&dir=xsh&file=lockf
[EACCES] or [EAGAIN]
       The function argument is F_TLOCK or F_TEST and the section is already
       locked by another process.
OTOH
http://www.db.opengroup.org/cgi-bin/dbcgi?CALLER=sud2/indx.tpl&TOKEN=FIYR&TPL=sd_fileframe&dir=xsh&file=fcntl
[EACCES] or [EAGAIN]
    The cmd argument is F_SETLK, and one of the following conditions
    is true:
        * The type of lock (l_type) is shared ( F_RDLCK) or exclusive
          ( F_WRLCK), and the segment of a file to be locked is
          already exclusive locked by another process.
        * The type of lock is exclusive, and some portion of the file
          segment to be locked is already shared locked or exclusive
          locked by another process.
Cheers,
  Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/