NFS recursive rm that fails, but succeeds on second try

[calyth]

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?

[bcwalrus]

Post by calyth
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