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.
> 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.
> 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.
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.
Ah, I did not know that. So, is WinRT a peer to Win32/Win64, or is it built atop Win32/Win64? I have heard that COM is bread and butter to the way Microsoft teams compose their systems, I should have known they would have based it on that. Maintaining the legacy through COM seems to encourage coupling in the design that would make it impossible to change out the OS underpinnings.
> I'd say NT especially is mostly on the right track in terms of being a modern kernel.
In the abstract, yes, NT is a vision of pure loveliness. NT 3.5 was super exciting when it came out, such a rock solid business OS (at the time)! Not sure what we got now in the concrete sense though - it's a real hodgepodge, new and old. I sense all the wise greybeards who could provide the vision have long since moved on.
I'm not suggesting Unix-like is a panacea, but it's on a better path than Windows as far as file systems go. There are surely optimizations and streamlining that a new design could showcase to blow away Unix/Linux/BSD. A new design from Microsoft would be refreshing, mainly because they have the cash and power to do it right and still offer their all-important backwards compatibility.
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?
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.