NFS recursive rm that fails, but succeeds on second try - NFS

This is a discussion on NFS recursive rm that fails, but succeeds on second try - NFS ; Since I didn't see this first hand, I'll try my best to describe this (and hope that someone has seen this). So there's a nfs share that's mounted on a Mac, and the user wanted to rm -fr (at least ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: NFS recursive rm that fails, but succeeds on second try

  1. NFS recursive rm that fails, but succeeds on second try

    Since I didn't see this first hand, I'll try my best to describe this
    (and hope that someone has seen this).
    So there's a nfs share that's mounted on a Mac, and the user wanted to
    rm -fr (at least probably some variant of rm -fr) a directory with
    subdirectories at least 6 levels deep.
    Somehow the rm command would fail at the 6th level and complains that
    the directory isn't empty, but when he tries the command again, rm
    succeeds without complaints.

    Has anyone see something similar to this?


  2. Re: NFS recursive rm that fails, but succeeds on second try

    On Jun 25, 3:37 pm, calyth wrote:
    > Since I didn't see this first hand, I'll try my best to describe this
    > (and hope that someone has seen this).
    > So there's a nfs share that's mounted on a Mac, and the user wanted to
    > rm -fr (at least probably some variant of rm -fr) a directory with
    > subdirectories at least 6 levels deep.
    > Somehow the rm command would fail at the 6th level and complains that
    > the directory isn't empty, but when he tries the command again, rm
    > succeeds without complaints.
    >
    > Has anyone see something similar to this?


    I haven't used a Mac client. But I can see how it's possible, if the
    client has an open file in that directory.

    When unlinking a file opened by some other process, the client
    typically renames it to a temporary file called something like
    ".nfsXYZ". So now the original file is gone from the namespace, and
    the process that has the file opened can still access it. (The actual
    removal of the temporary file happens when the file is closed.)
    However, from the "rm -rf" perspective, the directory is non-empty
    still and cannot be deleted, until the file is closed at a later time.

    Cheers,
    bc


+ Reply to Thread