fcntl cooperation with server side processes

James Peach jpeach at sgi.com
Tue Jul 27 03:44:57 GMT 2004

On Wed, Jul 21, 2004 at 08:37:18PM -0400, Chris Green wrote:
> David Collier-Brown wrote:
> >  Hmmn, as a command-like parameter, perhaps, called
> >something like --wait-for-exclusive_open ??
> >  Chris, this might be a suitable approach... opinions?
> I really think think the smbstatus + grep is the best cross platform 
> solution for me right now.  My main concern is making sure the entire 
> file is there so as long as I can see the file's status and know it's in 
> the process of being modified so that I can process the file and delete 
> it.    If I needed fancier semantics than that, I'd have no problem 
> writing a custom windows program to ensure the lock gets there.
> If  I understand correctly, the oplocks that say DENY_ALL will cause an 
> smbclient get to fail or block ( not sure on semantics and my notes are 
> at work ) so if I were to smbclient from myself, things would just 
> work.   The only problem would be attempting to connect to a remote 
> system and ensure that files are being copied.   In that case, being 
> able to specify the Deny Mode would be useful.
> Under Linux 2.4+, I think the problem is solved for me by attempting to 
> do a F_SETLEASE for a write lease.
> As long as any other process has the file open,  the kernel won't pass 
> out a write lease.
> The only problem with this method is that Linux returns an EACCESS 
> unless the uid of the file owner == uid of the file process.
> I've mailed the last 2 people that did changes to Linux to add the 
> leases to see why that is.   My feeling is that write leases should be 
> granted to anyone that has write permission to the file. 
> Does anyone know what the access restrictions  are under IRIX?

IRIX doesn't do leases. For oplocks you need to have the
CAP_NETWORK_MGT capability (or be root). I don't know the history of
the capability requirement, but Herb or Jeremy might.

James Peach | jpeach at sgi.com | SGI Australian Software Group
I don't speak for SGI.

More information about the samba-technical mailing list