I just want to ask if killing a specific procees might delete files being read of that process?
Here is the scenario: I execute nohup find . -type f |xargs ls -lrt > nohup1.out &
I noticed that it is taking so much space, I check that there are files so huge
.nfs* and keep on growing, I use fuser command to check what processes using that file and kill them all. The free space increases. I'm suspecting that it also checked other mountpoints so it runs forever.
I am not sure that killing those processes and removing those .nfs* has the possibility that it also delete files as well as directories. The command is just ls -lrt. Let me know if that is a possiblity.
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.