On Tue, 13 Sep 2005, Morgan wrote:

> "Ara.T.Howard" wrote:
>> O_EXCL is broken on nfs:
>> 
>>   O_EXCL When used with O_CREAT, if the file  already  exists  it  is  an
>>   error and  the open will fail. In this context, a symbolic link exists,
>>   regardless of where its points to.  O_EXCL is broken  on NFS file
>>   systems, programs which rely on it for performing lock- ing tasks will
>>   contain a race condition.  The solution for  per- forming  atomic  file
>>   locking  using  a lockfile is to create a unique file on the same fs
>>   (e.g.,  incorporating  hostname  and pid), use  link(2)  to  make  a link
>>   to the lockfile. If link() returns 0, the lock is successful.  Otherwise,
>>   use  stat(2)  on the  unique  file to check if its link count has
>>   increased to 2, in which case the lock is also successful.
>
> ... And I barely understood a word of that. `.`
>
> Does that mean it won't properly perform the "don't clobber an existing file"
> purpose I'm using it for?

it means that O_EXCL fails silently on some kinds of filesystems, including
nfs.  this is not likely to affect you and is beyond the control of ruby (it's
the c library/fs fault) but, if it does affect you, it means that two
instances of the code, when run at the same time, would __both__ be writing to
the file at the same time - neither would have an exclusive lock on the file
as it would not be created atomically.  basically you can ignore this if you
are working on local disk - but if you are some sort of shared setup like nfs
or windows equiv be wary.

cheers.

-a
-- 
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze.  --Nagarjuna
===============================================================================