[flagged]
The name calling and lack of actual examples shows that you probably haven’t even thought about potential downsides. I haven’t either, but it’s because I don’t really care about this particular issue. I just care enough to point out that the “mentally-challenged foot soldiers” at Microsoft may have actually run into some exploits or malicious behavior because they did “allow useful things” at one point.
[0]: https://devblogs.microsoft.com/oldnewthing/20050607-00/?p=35...
That's why people at Microsoft made those decision and not you. The most obvious reason would be to use the executable itself to back the memory which the comment you replied to already hinted at. Instead of loading the entire executable into memory on application start, you just create some memory mapping entry. As the code executes and accesses different parts of the executable, the page fault handler will load the required pages on demand. If you only access a small part of the executable, only a small part of the executable will ever be loaded into memory. If you run low on memory, you can just use the page frames holding the executable for other things, you can always load pages from the executable again if needed.
You can unlink a file and have a process still hold a reference to the inode. This allows you to continue reading (or executing) a file which may not have been fully mapped yet even after its last filesystem reference is gone.
There really isn't that much of a good reason to disallow deleting the files (assuming NTFS is capable of supporting a similar situation) except maybe for the fact that loosening a guarantee is still breaking an API in this scenario (someone might be relying on an executable file not being able to be deleted for some bizarre program feature).
I do wish Microsoft allowed more tweakables like this (so you can disable legacy behaviour if you feel you don't need it).
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.
Also, #3 is just unnecessary nitpicking.
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.
It's actually quite intriguing how this works.
When you delete a file on FAT it seems to remove the directory entry, but does not update the free space information and doesn't free the clusters. If you run a fsck.fat on a filesystem in this state, it frees up the space (likewise, if you just let the process exit and unmount the disk normally, this space is also freed).
Presumably the information about where the file exists is only kept in RAM once you delete the directory entry. This should be sufficient to let anyone with an open file handle etc to keep reading it (including the kernel reading additional pages of the executable).
If an open file is deleted, it's no longer enumerable in the file system. But its pages / blocks / whatever are still there on the disk, marked as used, and can back the page cache.
Once the file is closed, the filesystem notices that the blocks do not belong to a file accessible from outside, and garbage-collects the data blocks. It all closely resembles reference-counted GC.
So your entire comment was completely wrong. It’s not shameful to admit you’re wrong, it is shameful when someone else points out your mistake and you pivot to a “so what”.
> The most obvious reason would be to use the executable itself to back the memory which the comment you replied to already hinted at.
Imagine that I've already read that, and I still see no reason to do that. So what? The code of the program will go missing? -- What's the big deal? Kill the process. User wanted to remove it anyways... Let the user decide what to do: system shouldn't second guess me.
If your Linux doesn't do it -- I don't care. I'll make my Linux do it. Because that's how I want it to work.
And invariably I'd hit the most bonedeaded interviewers I'd ever talk to. Arrogance is common to all interviewers in the tech giants, Microsoft is no exception of course. But in the context of glaring lack of any kind of ability, arrogance hits a lot harder...
What also stands out is that programmers working for other companies would typically know something about the platform their company didn't use. Like, if you talk to a person at Google RSE department, they'd still know something about how things are on MacOS or on MS Windows. Microsoft programmers are completely oblivious to anything outside Microsoft. They believe that whatever garbage they came up with is the best thing there is never trying alternatives. But, in rare cases when they do, their knowledge is very distorted and superficial.
Here's a real case of someone who worked for Microsoft for about ten years and branded himself a "visual C++ programmer". This guy started about the same time with me in a company which was transitioning from a bunch of Windows tools to Linux. Part of the transition was to move away Perforce and to Git. It was the time when even small companies would self-host Git, and the typical way to do that was to create Linux users on the server hosting Git repo and give programmers SSH access to it.
The sysadmin there was new to Linux, but we were kind of friends, especially since I had more Linux experience, so he'd come and chat with me about his job. One evening he comes to me and starts asking about how'd I set up Wine. Intrigued by why he'd need that... soon I discover that the "visual C++ programmer" guy requested that the sysadmin install an FTP client on the server, so that he can access Git repo... and that FTP client has to be some Windows-only junk, and so the sysadmin though that maybe it would run on Wine.
It was so many stupid things and of such magnitude all at once... I almost had a spasm laughing. And that's, basically, how my experience with Windows programmers usually went. I never had a moment of "hey, this guy may be OK, not like the others" or anything close. Somehow it was always bizarrely otherworldly comedically stupid.