3 ms·

So you're saying, for example, that you can delete files that are currently open in another process in Windows? So not hypothetically: you've personally succe

So you're saying, for example, that you can delete files that are currently open in another process in Windows? So not hypothetically: you've personally succeeded at deleting a file on Windows that is currently open in another process? Also, is it the other process'es responsibility to open those file handles with the confusing, poorly documented, non-zero flags so that I can read/write/delete from my process? What if I don't own or control the other process? Am I just screwed in the majority of real-world cases? I suspect the problem here is a lot more complicated than me not setting open flags and getting all cross-eyed when visiting the CreateFile page at MSDN. The real problem is Microsoft's insane default file open semantics that do exclusive locks purely for the sake of compatibility with 30+ year old legacy. I've lost face on jobs because of file locking going on that was out of my control and creating havoc in my app. If we were targeting Linux, there wouldn't have been a problem, so the status quo is not okay. In my opinion, Win16/32/64 code should be sandboxed and only run in VM's in future OS'es; shed the legacy design decisions like pessimistic file locking completely. Trash the standard Windows API (not just hide it) and give me a next-generation Posix or CLR as a sane platform for new development.

mtdewcmu 13y ago
I've never done much Windows development, but even as a user, I've wondered what is up with the file locking. In the *nix world, deleting an open file is no problem. It just goes away when the last process closes it. In Windows, you can't drag a file to the Recycling Bin if an application has even used it recently, it seems. I always wondered what the heck that was for. So it's a legacy of DOS?
asveikau 13y ago
> that you can delete files that are currently open in another process in Windows? You can. However, there is an unfortunate behavior here that is different from Unix. When you delete an open file you cannot re-create one with the same name until the handle is dropped. (Once that gets to the NT APIs it will fail with STATUS_DELETE_PENDING until the last handle is dropped). You could work around this by doing rename + delete instead of just delete. I thought this behavior was dumb until I looked at the on-disk structure of FAT. No inodes. The filename is your inode. It makes it easier to implement a FAT driver if the semantics are such that the name entry sticks around until the file closes. That is a weak excuse, and sadly the people in the Windows division with the power to change this don't really care about it. (FYI, I worked in the Windows division from 2008-2011, not that I defend everything they do.) > poorly documented, non-zero flags so that I can read/write/delete from my process? Yeah, I agree this was kind of stupid. There are internal folks at MS, some of them quite influential, who think it's stupid too. But it's already been done. > The real problem is Microsoft's insane default file open semantics It's only "default" in that if you pass 0 it's what you get. If you think of "default" as FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE (and if everyone writing Windows software had that in their head) things would be a lot better. Granted that's a big if. > Trash the standard Windows API (not just hide it) This is the same fallacy a bunch of internal people came up with in Windows 8, however the truth is large chunks of the Windows API have nothing wrong with it. For example with what I'm sure are very simple changes in ntfs.sys, the corner cases around files being open [the ones I mentioned in my earlier post, not the ones around sharing flags if we consider them "by design"] go away, without invalidating every API in existence.
- EdSharkey 13y ago
  > You could work around this by doing rename + delete instead of just delete. That's um, inconvenient. I've heard similar tales, but I'd wager there are many more corner cases that could bedevil us. For example, what about .dll's and .exe's that are currently open in other processes? My experience has been that you simply cannot do anything with those files once they have been opened. The whole Windows file system just seems like a rat's nest of bad and worse design decisions. > Granted that's a big if. Stop. This is a bad design decision that has surely cost industry billions to reckon with and maybe cost a few lives along the way too. This is not the developer's fault. > Yeah, I agree this was kind of stupid. There are internal folks at MS, some of them quite influential, who think it's stupid too. But it's already been done. Hm, sounds like you're an insider! Right, well, I'm not satisfied with that blasé attitude. I think you ought to take more pride: Windows is kindof important, like, to humankind. It is really unethical to leave such bad designs in place, festering and impeding our progress and wasting our time. Your internal folks at MS who are clueful need to be heard. > > Trash the standard Windows API (not just hide it) > > This is the same fallacy a bunch of internal people came up with in Windows 8, however the truth is large chunks of the Windows API have nothing wrong with it. Seems to me that Windows RT could run on any kernel or VM. If that's the direction all development is going to take at MSFT, then do everyone a favor and chuck that boat anchor Win32 and plop the legacy apps into a VM ghetto running in seamless mode. Don't be afraid, just do the needful.
  - asveikau 13y ago
    > Hm, sounds like you're an insider! Was. As the comment you're replying to mentions in parenthesis, I wasn't there for all that long and I left a few years ago. Not that I in my lowly position would have been able to convince people to change some of this stuff... > Seems to me that Windows RT could run on any kernel or VM It's pretty heavily tied to Win32 and COM. I think the way you're talking about it is a little weird though. Would you criticize Android, for example, for having a Unix-like system underneath? I mean, 'cause Unix is like.. old, and stuff. </snark> Stuff simply being old isn't really a compelling reason to discard it. I'd say NT especially is mostly on the right track in terms of being a modern kernel. Not without its warts but it doesn't deserve comparison with DOS or 9x. COM has some good ideas at its core too.

mtdewcmu 13y ago

I've never done much Windows development, but even as a user, I've wondered what is up with the file locking. In the *nix world, deleting an open file is no problem. It just goes away when the last process closes it. In Windows, you can't drag a file to the Recycling Bin if an application has even used it recently, it seems. I always wondered what the heck that was for. So it's a legacy of DOS?

asveikau 13y ago

> that you can delete files that are currently open in another process in Windows? You can. However, there is an unfortunate behavior here that is different from Unix. When you delete an open file you cannot re-create one with the same name until the handle is dropped. (Once that gets to the NT APIs it will fail with STATUS_DELETE_PENDING until the last handle is dropped). You could work around this by doing rename + delete instead of just delete. I thought this behavior was dumb until I looked at the on-disk structure of FAT. No inodes. The filename is your inode. It makes it easier to implement a FAT driver if the semantics are such that the name entry sticks around until the file closes. That is a weak excuse, and sadly the people in the Windows division with the power to change this don't really care about it. (FYI, I worked in the Windows division from 2008-2011, not that I defend everything they do.) > poorly documented, non-zero flags so that I can read/write/delete from my process? Yeah, I agree this was kind of stupid. There are internal folks at MS, some of them quite influential, who think it's stupid too. But it's already been done. > The real problem is Microsoft's insane default file open semantics It's only "default" in that if you pass 0 it's what you get. If you think of "default" as FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE (and if everyone writing Windows software had that in their head) things would be a lot better. Granted that's a big if. > Trash the standard Windows API (not just hide it) This is the same fallacy a bunch of internal people came up with in Windows 8, however the truth is large chunks of the Windows API have nothing wrong with it. For example with what I'm sure are very simple changes in ntfs.sys, the corner cases around files being open [the ones I mentioned in my earlier post, not the ones around sharing flags if we consider them "by design"] go away, without invalidating every API in existence.

EdSharkey 13y ago
> You could work around this by doing rename + delete instead of just delete. That's um, inconvenient. I've heard similar tales, but I'd wager there are many more corner cases that could bedevil us. For example, what about .dll's and .exe's that are currently open in other processes? My experience has been that you simply cannot do anything with those files once they have been opened. The whole Windows file system just seems like a rat's nest of bad and worse design decisions. > Granted that's a big if. Stop. This is a bad design decision that has surely cost industry billions to reckon with and maybe cost a few lives along the way too. This is not the developer's fault. > Yeah, I agree this was kind of stupid. There are internal folks at MS, some of them quite influential, who think it's stupid too. But it's already been done. Hm, sounds like you're an insider! Right, well, I'm not satisfied with that blasé attitude. I think you ought to take more pride: Windows is kindof important, like, to humankind. It is really unethical to leave such bad designs in place, festering and impeding our progress and wasting our time. Your internal folks at MS who are clueful need to be heard. > > Trash the standard Windows API (not just hide it) > > This is the same fallacy a bunch of internal people came up with in Windows 8, however the truth is large chunks of the Windows API have nothing wrong with it. Seems to me that Windows RT could run on any kernel or VM. If that's the direction all development is going to take at MSFT, then do everyone a favor and chuck that boat anchor Win32 and plop the legacy apps into a VM ghetto running in seamless mode. Don't be afraid, just do the needful.
- asveikau 13y ago
  > Hm, sounds like you're an insider! Was. As the comment you're replying to mentions in parenthesis, I wasn't there for all that long and I left a few years ago. Not that I in my lowly position would have been able to convince people to change some of this stuff... > Seems to me that Windows RT could run on any kernel or VM It's pretty heavily tied to Win32 and COM. I think the way you're talking about it is a little weird though. Would you criticize Android, for example, for having a Unix-like system underneath? I mean, 'cause Unix is like.. old, and stuff. </snark> Stuff simply being old isn't really a compelling reason to discard it. I'd say NT especially is mostly on the right track in terms of being a modern kernel. Not without its warts but it doesn't deserve comparison with DOS or 9x. COM has some good ideas at its core too.