[linux-cifs-client] unlink behavior when file is open by other process

[Steve French]

Even when a file is open by another process, posix allows the file to
be deleted (the file is removed from the namespace and eventually the
data is removed from disk).   Unfortunately due to problems in some
NAS filers/servers this can be hard to implement, and I am not sure
what the "best" behavior is in that case.    Currently when unlink
fails with the cifs network status codes equivalent to ETXTBUSY, cifs
retries unlink by first renaming the file (ala nfs's "silly rename")
by file handle and then marking the file attribute as "delete on
close" (which will cause the server to unlink the file when the last
opener closes the file).   This is similar to the behavior required by
posix (although, like in nfs, the silly renamed file is temporarily
visible in the namespace, can't be reopened by anyone else).

Jeff Layton included a behavior change within a patch to fix another
problem with NTCreateX flags
(http://git.samba.org/?p=jlayton/cifs.git;a=commitdiff;h=f0c39587b7111deb13e56e5a521c5f3d8278cf5e)
that I just merged that will break this (delete of open files) to at
least one popular filer because that filer does not support rename by
handle (rename of open file is one of the SMB transact2 levels, and
one that most servers support).   His patch would give up in
cifs_unlink if we can't "silly-rename" the file.   I have mixed
feelings about this since with current code we can delete the file
(mark the file delete on close) but we can't rename it (we could hide
it in the namespace but it obviously can't be completely transparent
because you can't create a file of the same name).

Is it better to fail unlink if the file can't be removed from the
namespace immediately or better to allow unlink (but then some
applications will get an access denied on open if they try to create a
file of the same name before the original opener closes the file)?

-- 
Thanks,

Steve