lkml.org 
[lkml]   [2008]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectunlink behavior when file is open by other process
    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


    \
     
     \ /
      Last update: 2008-10-17 17:19    [W:0.021 / U:29.832 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site