On 12-05-07 10:09 AM, Steve Singer wrote:
> On 12-05-05 10:14 AM, Jan Wieck wrote:
>> On 5/2/2012 5:39 PM, Steve Singer wrote:
>
>
>> I have attached a small patch against 2.0 that changes the opening of
>> the temporary archive file to use O_CREAT|O_EXCL and then fdopen(3).
>> This would cause proc2 above to fail with an error because the file
>> already exists. This will tell you in the slon logs which slon is
>> actually doing this.
>
> The Linux documentation for O_EXCL states:
>
> ------
> O_EXCL is only supported on NFS when using NFSv3 or later on kernel 2.6
> or later. In environments where NFS O_EXCL support is not provided,
> programs that rely on it for performing locking tasks will contain a
> race condition. Portable programs that want to perform atomic file
> locking using a lockfile, and need to avoid reliance on NFS support for
> O_EXCL, can create a unique file on the same file system (e.g.,
> incorporating hostname and PID), and use link(2) to make a link to the
> lockfile. If link(2) 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.
> ----------
>
> I can see people wanting to put their log shipping spool directory on an
> NFS share. Have many NAS appliances out there still only support NFS v2?
>

The AIX man page (open) says

---
O_EXCL If the O_EXCL and O_CREAT flags are set, the open is unsuccessful 
if the file exists. Note: The O_EXCL flag is not fully supported for 
Network File Systems (NFS). The NFS protocol does not
guarantee the designed function of the O_EXCL flag.
-----------

Can we think of another way of ensuring the file doesn't exist?


> How does O_EXCL behave against a CIFS share?
>
> How does this call work on Win32?
>
>
>
>
>
>>
>>
>> Jan
>>
>