But closing a file may indeed delete it. We get this question quite a bit. Someone will do something like:
yes > really.big.file &
and observe that really.big.file has consumed all of the disk space in a filesystems. They then do "rm really.big.file" and post a question wondering why the space was not freed. The rm command simply removes the lasy hard link to the file. But the file is still open so the space will not be freed. The space will be freed when the last process that has it open finally closes it.

A more complex situation arises when two processes on a single NFS client open a file on a NFS server. Should one of the processes wish to delete the file, the client code will detect that a second process has it open. To perserve the integrity of the filehandle the client will rename the file to a hidden name and with most implementations, .nfsnnnnn is the name that is used. When the last process on the NFS client closes the file, the NFS client code will indeed delete the .nfsnnnnn file. This is not a super robust solution and it screws up if multiple processes have the file opened on different NFS clients, and this will usually result in stale filehandles. But I'm just the messenger.