On Fri, Oct 17, 2008 at 10:09 AM, Steve French <smfrench@xxxxxxxxx> wrote: > 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)? The two particular examples: 1) An application that does: open, unlink, close, create used to always work but now would fail unless the server/filer has rename-by-handle support 2) An application that does: open, unlink, create used to fail (with access denied on create) when the server did not have rename-by-handle support but now (with Jeff's patch sideeffect) will fail on unlink. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
