From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Steve French" Subject: Re: unlink behavior when file is open by other process Date: Fri, 17 Oct 2008 10:24:29 -0500 Message-ID: <524f69650810170824x4f9ff975qb03d687c8d3557ff@mail.gmail.com> References: <524f69650810170809u2df1a309o2f357dc8489c06c6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: linux-fsdevel , "linux-cifs-client@lists.samba.org" , "Jeff Layton" To: LKML Return-path: Received: from mail-gx0-f16.google.com ([209.85.217.16]:52905 "EHLO mail-gx0-f16.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753776AbYJQPYc (ORCPT ); Fri, 17 Oct 2008 11:24:32 -0400 Received: by gxk9 with SMTP id 9so1195444gxk.13 for ; Fri, 17 Oct 2008 08:24:30 -0700 (PDT) In-Reply-To: <524f69650810170809u2df1a309o2f357dc8489c06c6@mail.gmail.com> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Oct 17, 2008 at 10:09 AM, Steve French 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