4 ms·

It has little to do with the filesystem. Windows has OS level locks. In the case of a running executable, the mapped memory holds a lock on the exe file to prev

It has little to do with the filesystem. Windows has OS level locks. In the case of a running executable, the mapped memory holds a lock on the exe file to prevent deleting it. This is intentional. If it didn't hold the lock then it would be possible to delete the exe file on modern versions of Windows. Edit: since there still seems to be confusion I'll try to be clearer. On NTFS you can delete an open file. This is a solved problem. The DeleteFile API even does this by default now. The thing that prevents deletion is an OS lock. This lock only prevents deletion. Renames are still allowed.

crabbone 3y ago
[flagged]
- pc86 3y ago
  There are some brilliant people at Microsoft. Maybe not in the product end of things, but there are very few brilliant product people anywhere ;)
  - crabbone 3y ago
    Obviously I cannot know everyone working for Microsoft. But I do know few people. Also, since I would never work for Microsoft, at the times I spent many years working for the same employer and either wanted to practice interviewing because I thought I might be headed for the door soon, or just to keep things fresh, I'd apply for jobs with Microsoft. 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.
- danbruc 3y ago
  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).
- _gabe_ 3y ago
  There’s a Raymond Chen article (or maybe it’s in his book) about people that complain “why doesn’t windows just let me do…”, and he then goes on to give several examples and show what some of the downsides are if you allowed it. This article looks similar, but I’m not sure it is[0]. 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=35413 https://devblogs.microsoft.com/oldnewthing/20050607-00/?p=35...
jcarrano 3y ago
I didn't know about the lock. What happens when you delete an open file in NTFS? Is the data still accessible for programs that have the file open? If yes, then why the lock. If not, then that's a problem.

crabbone 3y ago

[flagged]

pc86 3y ago
There are some brilliant people at Microsoft. Maybe not in the product end of things, but there are very few brilliant product people anywhere ;)
- crabbone 3y ago
  Obviously I cannot know everyone working for Microsoft. But I do know few people. Also, since I would never work for Microsoft, at the times I spent many years working for the same employer and either wanted to practice interviewing because I thought I might be headed for the door soon, or just to keep things fresh, I'd apply for jobs with Microsoft. 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.
danbruc 3y ago
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).
_gabe_ 3y ago
There’s a Raymond Chen article (or maybe it’s in his book) about people that complain “why doesn’t windows just let me do…”, and he then goes on to give several examples and show what some of the downsides are if you allowed it. This article looks similar, but I’m not sure it is[0]. 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=35413 https://devblogs.microsoft.com/oldnewthing/20050607-00/?p=35...

jcarrano 3y ago

I didn't know about the lock. What happens when you delete an open file in NTFS? Is the data still accessible for programs that have the file open? If yes, then why the lock. If not, then that's a problem.