Question 1:
I write a c program which just only has a while infinite loop, while it executes, in another shell login, I remove the executable file. The linux OS doesn't complain anything, and the executable file continues executing. In windows box, the OS wouldn't let you remove the executing files at all.
So can some guru explain how does Linux work in such situation?

Question 2:
Before, when I update a program, I use the steps below:
1. Change the code 2.Stop the executing program 3.compile and overwrite the executing program 4.start the program

According to the test of Question 1, Can I do as follows? Is it always safe?
1.Change the code 2.compile and overwrite the executing program 3.Stop the executing program 4.start the program
Thanks in advance!

Hi,

1. The running program has already been loaded into ram so it makes no difference if the file is removed from the disk.
2. a) Yes you can.
b) Not sure, but I guess so.

HTH,

Evo2.

Note: not every Unix supports overwriting running program-files. The correct way is delete+recreate. (Files in use aren't actually deleted when you call unlink(1), only when no more process uses them. (Directory entries, on the other hand, are deleted by unlink(1) immediately.))

In Linux, Mac OS X, and many other Unix-like systems, filesystems use inodes. Basically, the name and the actual file are separate entities. When you delete a file, the kernel does not immediately delete the file if some process has it open, it just marks the inode deleted. Only when the last handle to the inode is closed, is the inode actually deleted.

All inodes the kernel is currently executing are marked busy. You won't be able to modify such files, but you can remove them. Because of the mechanism I described above, removing the file causes the file to become inaccessible, but will not release the disk space until the file is no longer being executed (and has no open handles to it).

Script files can be edited, because they're not executed by the kernel, but by a script interpreter.

In Linux and Unix, it is a very common, traditional technique to create a temporary file, then delete it immediately, but not close it. You can still read and write to the file normally, truncate or extend it, but as soon as the program exits, the file contents will vanish too. You can even give other processes access to the file in Linux by using name /proc/PID/fd/DESCRIPTOR where PID is the process ID of the creator process, and DESCRIPTOR is the file descriptor number (the handle to the open file).

Nope. You do not overwrite the file, not really: the file gets replaced. The data in the file does not get overwritten, it is replaced by a new file.

Yes, it is always safe in Linux, and in all Unix-like systems I've ever used.

3 members found this post helpful.

Note: in AIX, if I try to link an already running executable, 'ld' will give an error message (ETEXTBUSY), then deletes the executable, so the second try will work... The correct solution: remove the existing file first, then perform linking.

When a program is executing, portions of the executable file are often memory-mapped into the process address space. Even if the directory-entry pointing to the inode can be removed, the inode itself probably cannot. Generally speaking, you can't in any operating system succeed in causing a program to remove itself from disk.

You can access it via procfs, actually. But there's no "normal" way to access it once it's been deleted.
Kevin Barry

Good point.

/proc/PID/exe is actually quite an interesting feature. When the binary is deleted, the symlink will show up as /path/to/binary (deleted). However, when opened, the kernel returns a handle to the original inode instead. Many of the files in /proc/ behave this way in Linux, particularly the /proc/PID/fd/DESCRIPTOR ones: they look like symlinks, but provide access to process (or kernel) internals.

FreeBSD no longer provides procfs by default, so anything involving /proc/ should probably be considered more or less Linux-specific.