[linux-cifs-client] Re: Fwd: CAR - Missing information about DELETE_ON_CLOSE

[Jeff Layton]

On Fri, 26 Sep 2008 14:32:16 -0400
Jeff Layton <jlayton at redhat.com> wrote:

> On Thu, 25 Sep 2008 10:57:48 -0500
> "Steve French" <smfrench at gmail.com> wrote:
> 
> Thanks for forwarding this along...
> 
> I've gone over it in more detail. I think the upshot of this is that we
> need to avoid using CREATE_DELETE_ON_CLOSE for the cifs_unlink code
> since its semantics are a bit different from the other methods. I'll
> plan to respin the patches in my tree that you haven't taken yet to
> account for this.
> 
> Another interesting bit is that it looks like we don't need to use the
> SetFileDisposition call but may be able to set this in the SetFileInfo
> call. IIRC though, my results with trying to set this bit via other
> means was iffy. I'll experiment some more and see what works.
> 
> Thanks,
> Jeff
> 

Ok, I did a bit of experimentation, and it looks like setting
ATTR_DELETE_ON_CLOSE in a SET_FILE_INFO call doesn't seem to actually
have any affect against windows or samba. I haven't tested
SET_PATH_INFO,
but it's hard to believe that it'll do anything different.

FWIW, I can see the bit set in the raw packet data, but wireshark
doesn't seem to decode it -- it doesn't seem to think that the
high-order bits in the FILE_BASIC_INFO Attributes field are
meaningful.

I think the only thing we can reasonably do is to declare busy-file
deletes on samba w/o unix extensions broken until JRA's patch goes in,
and return the error that SetFileDisposition returns. That's probably
OK, most people using CIFS VFS against samba are probably using unix
extensions. For those that aren't, we can just tell them to patch their
samba server. This means we'll probably want to basically back out the
patch that added those in. 

Also, I think not returning error back to the caller when the rename by
filehandle fails is wrong. The file will still be present, so the unlink
didn't work by any real definition. It doesn't seem like we should pretend
that it did.

I'll fix up my tree with the way that I think that should be and we can
continue the discussion based on that.
-- 
Jeff Layton <jlayton at redhat.com>