1. I know how Ext4 works in this case, and I don't care.
2. I already explained how I would like the system to respond. Ext4 or any other filesystem have nothing to do with it.
3. Processes don't hold references to inodes. That's nonsense (simply because there's no such thing as a "reference to inode" in any system interface). Process doesn't get a reference to the file from which its executable code is loaded at all (unless you count the first argument -- but that's the file's name, not the file). Who put this idea in your mind I don't know... and any filesystem, be it Ext4 or anything else has no role to play in this. Now, the loader may decide to store the inode of a file or not -- yeah, whatever. A filesystem may even decide to change the inode of an existing file, if it so wants -- since there's no system interface that relies on inodes, it's all a fair game. For example, Shell will usually read the text of a script it's executing a block or maybe even just a line at a time. If you modify the file during its execution, it's usually going to cause syntax errors, but, if you are lucky, you can even write self-modifying programs in Shell. Now, will Shell perform like this if inode changes? -- Knowing Linux tools, I'd say, probably not. Will probably fail in some spectacular way. But do I care? -- Nope. I want this power to delete the executable file as it's being executed. I see no reason not to have such power.
I know how Ext4 works in this case, and I don't care.
I think the comment to learn about Ext4 was aimed at me.
I already explained how I would like the system to respond. Ext4 or any other filesystem have nothing to do with it.
As I explained before, Windows - and also Linux - made the reasonable decision to back the memory of a process with the executable file so that the memory can be easily paged in and out. This decision forces you to make the executable file non-deletable while the process is running.
This is true for Windows and Linux, neither of them will delete the executable file while the process is running. Some file system including Ext4 and NTFS support initiating a delete while the file is still in use, which will make the file look deleted and eventually also delete the file. But this does not truly delete the file until the process exits, i.e. you can not reuse the disk space of the executable file immediately.
So depending on what you want from deleting the executable file while a process is running - do you only want it to look deleted and eventually disappear or do you want to reuse the space of the executable file - the file system might give you what you want even if processes are backed by their executable files. Or it might not.
Processes don't hold references to inodes. That's nonsense (simply because there's no such thing as a "reference to inode" in any system interface).
It would of course be a bad idea if processes would know about inodes, that is an implementation detail and not all file system use inodes. That does however not mean that processes can not hold references to inodes, a file descriptor is a reference to some file which will be implemented as a reference to an inode for Ext4.
Process doesn't get a reference to the file from which its executable code is loaded at all (unless you count the first argument -- but that's the file's name, not the file).
The process does not get that reference but the executable file is loaded as a memory mapped file, so the virtual memory manager will have a file descriptor for the executable file and indirectly reference an inode on file systems using them.
I want this power to delete the executable file as it's being executed. I see no reason not to have such power.
You can have this if you give up loading executables as memory mapped files. Or, if it is good enough for you that the file looks deleted and eventually gets deleted but the disk space does not become reusable until the process exits, if you use a file system that supports deleting open files.
Take some embedded system, you habe 4 MiB RAM, 8 MiB flash, 7 MiB executable. The only way to run this executable is by loading it as a memory mapped file, you can neither load it completely into memory nor can you create a big enough swap file.
2. I already explained how I would like the system to respond. Ext4 or any other filesystem have nothing to do with it.
3. Processes don't hold references to inodes. That's nonsense (simply because there's no such thing as a "reference to inode" in any system interface). Process doesn't get a reference to the file from which its executable code is loaded at all (unless you count the first argument -- but that's the file's name, not the file). Who put this idea in your mind I don't know... and any filesystem, be it Ext4 or anything else has no role to play in this. Now, the loader may decide to store the inode of a file or not -- yeah, whatever. A filesystem may even decide to change the inode of an existing file, if it so wants -- since there's no system interface that relies on inodes, it's all a fair game. For example, Shell will usually read the text of a script it's executing a block or maybe even just a line at a time. If you modify the file during its execution, it's usually going to cause syntax errors, but, if you are lucky, you can even write self-modifying programs in Shell. Now, will Shell perform like this if inode changes? -- Knowing Linux tools, I'd say, probably not. Will probably fail in some spectacular way. But do I care? -- Nope. I want this power to delete the executable file as it's being executed. I see no reason not to have such power.