5 ms·

I see no reason not to allow this. That's why people at Microsoft made those decision and not you. The most obvious reason would be to use the executable itsel

I see no reason not to allow this. 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.

Arch-TK 3y ago
I think maybe you should familiarise yourself with how e.g. ext4 works. 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).
- danbruc 3y ago
  What happens when you run an executable from a FAT formatted partition under Linux, then I would guess Linux also no longer allow deleting the file while it is running, right? In the end this is a feature of the file system, can you delete open files?
  - Arch-TK 3y ago
    On Linux you can unlink open files even on a FAT formatted partition (I just tried it with busybox). 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).
    - danbruc 3y ago
      So essentially the same as with Ext4, either sans the orphan list or maybe they even store one somewhere so that they can clean up while mounting in case the system crashed.
- crabbone 3y ago
  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.
  - danbruc 3y ago
    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.
phh 3y ago
As the original comment mention, this issues doesn't exist on Linux because the FS is inode based. The file content will be removed only when the last user has been removed.
- danbruc 3y ago
  So what? Building an operating system necessarily requires making countless design decisions, trading some things for other things. Over the decades the best choices may even change as technology advances but you might be unable to change course because you have a huge number of installations and would cause a lot of issues.
  - oefrha 3y ago
    > So what? 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”.
    - danbruc 3y ago
      No, you are confusing things - reasons are not necessities.
crabbone 3y ago
I have very little respect to people at Microsoft when it comes to technical side of things. Whenever I have to deal with their "creations" it's like they were motivated by malice, or part of their frontal cortex gone missing. > 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.
- radlad 3y ago
  Most users do not want a running program to corrupt / crash on them - even if they deleted the backing exe.
  - kaibee 3y ago
    In practice, this isn't really true? Like, when do users delete programs manually anymore? Its almost always some uninstaller doing it from some installed appstore type program (Steam, Adobe Cloud, etc). And usually the user is deleting the whole directory, which almost always has additional files that the program needs to actually work. Those files will be deleted so their install already gets corrupted either way.
  - crabbone 3y ago
    So what? I want it, and I see no reason not to let me have it. Linux was designed with this main goal in mind: let people take ownership of their computers and do whatever the hell they want with them. 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.
webstrand 3y ago
This is exactly what linux does too, inodes just let users delete/move the file on disk while the executable is running.
nine_k 3y ago
This is reasonable, but this does not necessarily preclude the file from being deleted from the directory. 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.

Arch-TK 3y ago

I think maybe you should familiarise yourself with how e.g. ext4 works. 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).

danbruc 3y ago
What happens when you run an executable from a FAT formatted partition under Linux, then I would guess Linux also no longer allow deleting the file while it is running, right? In the end this is a feature of the file system, can you delete open files?
- Arch-TK 3y ago
  On Linux you can unlink open files even on a FAT formatted partition (I just tried it with busybox). 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).
  - danbruc 3y ago
    So essentially the same as with Ext4, either sans the orphan list or maybe they even store one somewhere so that they can clean up while mounting in case the system crashed.
crabbone 3y ago
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.
- danbruc 3y ago
  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.

phh 3y ago

As the original comment mention, this issues doesn't exist on Linux because the FS is inode based. The file content will be removed only when the last user has been removed.

danbruc 3y ago
So what? Building an operating system necessarily requires making countless design decisions, trading some things for other things. Over the decades the best choices may even change as technology advances but you might be unable to change course because you have a huge number of installations and would cause a lot of issues.
- oefrha 3y ago
  > So what? 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”.
  - danbruc 3y ago
    No, you are confusing things - reasons are not necessities.

crabbone 3y ago

I have very little respect to people at Microsoft when it comes to technical side of things. Whenever I have to deal with their "creations" it's like they were motivated by malice, or part of their frontal cortex gone missing. > 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.

radlad 3y ago
Most users do not want a running program to corrupt / crash on them - even if they deleted the backing exe.
- kaibee 3y ago
  In practice, this isn't really true? Like, when do users delete programs manually anymore? Its almost always some uninstaller doing it from some installed appstore type program (Steam, Adobe Cloud, etc). And usually the user is deleting the whole directory, which almost always has additional files that the program needs to actually work. Those files will be deleted so their install already gets corrupted either way.
- crabbone 3y ago
  So what? I want it, and I see no reason not to let me have it. Linux was designed with this main goal in mind: let people take ownership of their computers and do whatever the hell they want with them. 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.

webstrand 3y ago

This is exactly what linux does too, inodes just let users delete/move the file on disk while the executable is running.

nine_k 3y ago

This is reasonable, but this does not necessarily preclude the file from being deleted from the directory. 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.