On Mon, May 30, 2011 at 7:46 PM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote: > Hi all.. > > > On Tue, May 31, 2011 at 08:25, Pei Lin <telent997@xxxxxxxxx> wrote: >> 2011/5/30 Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>: >>> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
