Whenever we try to execute a binary file, the loader copies essential chunks of code/data (entry point) from the binary in to the memory. Then it passes control to the corresponding process.
If a process tries to execute/access a piece of code/data which is not still in the memory, the kernel page-fault handler loads the required code/data from the binary file (demand paging). However, if the binary is already deleted, it leads the process to be terminated by the kernel (Invalid access, since the required content could not be found on the media).
For small binaries, this may not be the case because the whole file content might have already been copied to the memory. Thus the deletion of the binary from the disk doesn't have any effect.
Linux uses demand paging to load executable images into a process's virtual memory. Whenever a command is executed, the file containing it is opened and its contents are mapped into the process's virtual memory. This is done by modifying the data structures describing this process' memory map and is known as memory mapping. However, only the first part of the image is actually brought into physical memory. The rest of the image is left on disk. As the image executes, it generates page faults and Linux uses the process's memory map in order to determine which parts of the image to bring into memory for execution.
PS: It should be clear by now, regarding who needs a brush-up of UNIX basics... :-)
This part of your answer was actually correct, just it did not at all answer the question. You just explained why deleting the binary could be a problem /at all/ with paged memory (a simple OS like DOS just loads the program completely into RAM before starting it, you can take out the program disk and stow it away once your program is loaded, before inserting the data disk (you in fact _had to do this_ in a one floppy no harddisk PC)). So you just /explained/ the question :)
But as the parent poster unsuccessfully tried to tell you, it has to do with inodes and directories; you just got into defense mode instead of further researching.
'rm' just unlink()s the inode (which holds the file's contents), i.e. decrements the use count and removes the directory entry, but /using/ a file (having it opened, or as current directory, or as paging backing store (as the executable) (i.e. mmap()ed)) incremented the use count and the data is only deleted, when the use count is zero, i.e. the last user vanished. Try "mkdir a; cd a; rmdir ../a; ls -la; ls -la .." as a test. This is a standard Unix feature and e.g. allows to upgrade system software without reboots or really secure temporary files (you delete them before use, so nobody can find them, and they automatically get removed when your program closes them or exits).
You can of course /change/ the file data (if the OS allows this), or delete a file the program needs but has not opened yet; this in fact leads to crashes.
Linux allows files to be deleted when they are in use.
The file can no longer be accessed by name, but the program(s) that were using the file can still read and write to it. This includes the case where a binary is deleted and the program continues running.
The file is removed from disk when it is no longer in use.
Windows does not allow files that are in use to be deleted, which is why you have to reboot after installing anything.
Whenever we try to execute a
Whenever we try to execute a binary file, the loader copies essential chunks of code/data (entry point) from the binary in to the memory. Then it passes control to the corresponding process.
If a process tries to execute/access a piece of code/data which is not still in the memory, the kernel page-fault handler loads the required code/data from the binary file (demand paging). However, if the binary is already deleted, it leads the process to be terminated by the kernel (Invalid access, since the required content could not be found on the media).
For small binaries, this may not be the case because the whole file content might have already been copied to the memory. Thus the deletion of the binary from the disk doesn't have any effect.
Regards,
Narendra Kiran Chinnam.
Excuse me, but this is simply
Excuse me, but this is simply not true.
Read up on inodes & directories (i.e. Unix basics).
Please go through the last pa
Please go through the last paragraph under "Demand Paging" section in the following URL. It clearly explains how a program is loaded.
http://www.linux-tutorial.info/modules.php?name=Tutorial&pageid=89
It goes on like this...
Linux uses demand paging to load executable images into a process's virtual memory. Whenever a command is executed, the file containing it is opened and its contents are mapped into the process's virtual memory. This is done by modifying the data structures describing this process' memory map and is known as memory mapping. However, only the first part of the image is actually brought into physical memory. The rest of the image is left on disk. As the image executes, it generates page faults and Linux uses the process's memory map in order to determine which parts of the image to bring into memory for execution.
PS: It should be clear by now, regarding who needs a brush-up of UNIX basics... :-)
Regards,
Narendra Kiran Chinnam.
this part was correct, but not the answer
This part of your answer was actually correct, just it did not at all answer the question. You just explained why deleting the binary could be a problem /at all/ with paged memory (a simple OS like DOS just loads the program completely into RAM before starting it, you can take out the program disk and stow it away once your program is loaded, before inserting the data disk (you in fact _had to do this_ in a one floppy no harddisk PC)). So you just /explained/ the question :)
But as the parent poster unsuccessfully tried to tell you, it has to do with inodes and directories; you just got into defense mode instead of further researching.
'rm' just unlink()s the inode (which holds the file's contents), i.e. decrements the use count and removes the directory entry, but /using/ a file (having it opened, or as current directory, or as paging backing store (as the executable) (i.e. mmap()ed)) incremented the use count and the data is only deleted, when the use count is zero, i.e. the last user vanished. Try "mkdir a; cd a; rmdir ../a; ls -la; ls -la .." as a test. This is a standard Unix feature and e.g. allows to upgrade system software without reboots or really secure temporary files (you delete them before use, so nobody can find them, and they automatically get removed when your program closes them or exits).
You can of course /change/ the file data (if the OS allows this), or delete a file the program needs but has not opened yet; this in fact leads to crashes.
oops,I did not know that. Tha
oops,I did not know that. Thanks for the excellent explanation.
Regards,
Narendra Kiran Chinnam.
The file has not been completely removed
Linux allows files to be deleted when they are in use.
The file can no longer be accessed by name, but the program(s) that were using the file can still read and write to it. This includes the case where a binary is deleted and the program continues running.
The file is removed from disk when it is no longer in use.
Windows does not allow files that are in use to be deleted, which is why you have to reboot after installing anything.
Over writting libc with its copy hangs system
Over-write libc with its own copy, the whole system hangs. What is the explantion for this.
What is the explanation for y
What is the explanation for you wanting to do things like these?