Server-side silly rename

The NFSv3 protocol has no way to say "I'm unlinking this file, but please keep it around because I have an application that's still using it".  So if the client wants to provide unix-like semantics, it has to resort to this hack (called "silly rename") on unlink of an open file.  See also [http://nfs.sourceforge.net/#section_d], or the earliest description I'm aware of, in [https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.473 "Design and Implementation of the Sun Network Filesystem" (1985)]:

<blockquote>
We tried very hard to make the NFS client obey UNIX filesystem
        semantics without modifying the server or the protocol. In some
        cases this was hard to do. For example, UNIX allows removal of
        open files. A process can open a file, then remove the directory
        entry for the file so that it has no name anywhere in the
        filesystem, and still read and write the file. This is a
        disgusting bit of UNIX trivia and at first we were just not
        going to support it, but it turns out that all of the programs
        that we didn't want to have to fix (csh, sendmail, etc.) use
        this for temporary files.

        What we did to make open file removal work on remote files was
        check in the client VFS remove operation if the file is open,
        and if so rename it instead of removing it. This makes it (sort
        of) invisible to the client and still allows reading and
        writing. The client kernel then removes the new name when the
        vnode becomes inactive. We call this the 3/4 solution because if
        the client crashes between the rename and remove a garbage file
        is left on the server. An entry to cron can be added to clean up
        on the server.

</blockquote>

NFSv4 actually does have open and close calls, and our server won't free a file until last close.  Until the server reboots, at which point the file will diseappear even though an application on the client is still using it.  NFS is supposed to keep working normally across server reboots.  So the client still does silly rename even in the v4 case.

Silly rename is not an imperfect solution.  The ".nfsXXXX files that it leaves around are still noticed by users sometimes, such as when they try to remove a directory that contains them.  And it doesn't help if a file is unlinked by a different client than the one that holds it open.

We could actually move the responsibility for silly rename to the server--the server could keep a hardlink to the file after unlink, and
that would preserve the file after reboot as well.  (And it could use a separate directory for the purpose, and avoid the rmdir).  We even added a bit to the NFSv4 protocol so that the server can tell the client it does this, allowing the client to skip sillyrename: