[lkml]   [2008]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-cifs-client] Re: unlink behavior when file is open by other process
    On Fri, Oct 17, 2008 at 12:27 PM, Jeff Layton <> wrote:
    > On Fri, 17 Oct 2008 10:24:29 -0500
    > "Steve French" <> wrote:
    >> 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.
    > My argument is that the primary function of unlink() is to remove a
    > filename from the filesystem. If we return success from such a call
    > without actually having freed up that filename, then that's a bug. It's
    > unfortunate that some servers don't support the calls we need to make
    > this work all the time.
    The filename will be freed - and the trade off is which breaks fewer apps.
    Both open and unlink man pages list plausible return codes but I
    am worried that the sequence of file operations open/unlink/close
    (I think we see both dbench and connectathon do this IIRC)
    is as common a a sequence as open/unlink/create/close
    thus we could break more apps your way than leaving it as is.

    > We can't however make assumptions about what applications want. We
    > could, in principle, fix up the situation where a server does
    > open->unlink->create by truncating the old file and pretending that
    > it's a new one.
    That could corrupt data - the original opener may need that data up
    to the moment they close that handle.

    > All we can reasonably do is try to have each syscall give us the
    > expected end result or an error if it can't be done.
    The open syscall is allowed to fail with ETXTBUSY (or even access
    denied among other).
    Although this type of situation is not common on open, it more common in
    open (and create) than on unlink and thus A likely that an app could deal with
    an open error than on the unlink that preceeded it. The other argument
    here is that whether or not we allow unlink (when it can be marked for deletion
    but not silly renamed) - we have apps that will get the same error on open due
    to Windows, MacOS and other non-Linux clients setting the flag (ie open/create
    failures for a filename that was marked delete-on-close can still
    happen even if we aren't the
    ones who set the flag on the file since Windows and various other OS can and do
    set this file on the server or remotely)



     \ /
      Last update: 2008-10-17 19:43    [W:0.025 / U:10.456 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site