On Mon, May 30, 2011 at 7:46 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
Hi all..
On Tue, May 31, 2011 at 08:25, Pei Lin <telent997@gmail.com> wrote:
2011/5/30 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
Hi all..
As the subject says, I was thinking about that issue.
I know that rm-ing a file doesn't delete the data block from the backing device, thus the executable could still survive and running.
But logically, we usually expect that once a file is rm-ed, it should also "stop", right? What does POSIX say about this case anyway? Anyone could kindly give his/her opinion? In my view, i don't expect that rm one file should also stop the related process. If that, in one system, do the thing "rm sysfile" will stop OS running? In my logic, i just think run the executable is the user's choice before "rm it", if the user want to delete file, also who want to stop the process related this file should kill the process themselves. I consider that if the users delete one file uncarefully, should give the chance to recover it and not block current running task.
Thanks for sharing your thoughts so far. This came to my mind when I did a project about 2 years ago. At that time, I also came to very much same conclusion: if you want to make sure new binary is executed, sigkill/sigterm the old ones first, remove them and run the new one. Seems trivial, but initially this tiny little detail missed from my mind.
How will "rm /bin/rm" work otherwise ? -- Thanks - Manish