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?

How does O_EXCL behave against a CIFS share?

How does this call work on Win32?





>
>
> Jan
>