3 ms·

Oh, and Microsoft, if I have a process that opens a file, could you PLEASE stop locking the file in your weird and arbitrary ways? How many times have I had to

Oh, and Microsoft, if I have a process that opens a file, could you PLEASE stop locking the file in your weird and arbitrary ways? How many times have I had to kludge my code for running on Windows because of file locking policies that were in place for, what, DOS 3 compatibility? It's no wonder to me why deploying to Linux is so popular. Draconian file locking policies in Windows, huge PITA right out the chute.

asveikau 13y ago
Usually this is the application's fault. When you open a file with the Windows API there is a bit mask of what another handle can do (read, write, and delete/rename). The problem occurs when you specify 0 for this parameter because you're looking at MSDN and you don't know what any of this means. That locks out concurrent access to the file. There are some other weird behaviors that probably shouldn't be there (such as renaming the parent of an open file or the behavior when an open file is deleted) but an application misusing the sharing flags is probably what you're thinking of.
- EdSharkey 13y ago
  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
maaaats 13y ago
This is really not that relevant, and entirely your own fault in writing your program wrong.
- rbanffy 13y ago
  So, what is the correct way to open a file in such way you can still read (or write it) it if another process moves/renames/deletes it? Are you implying everyone who ever wrote an installer that can't install something without a reboot lacks proper understanding of how to open files?

asveikau 13y ago

Usually this is the application's fault. When you open a file with the Windows API there is a bit mask of what another handle can do (read, write, and delete/rename). The problem occurs when you specify 0 for this parameter because you're looking at MSDN and you don't know what any of this means. That locks out concurrent access to the file. There are some other weird behaviors that probably shouldn't be there (such as renaming the parent of an open file or the behavior when an open file is deleted) but an application misusing the sharing flags is probably what you're thinking of.

EdSharkey 13y ago
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

maaaats 13y ago

This is really not that relevant, and entirely your own fault in writing your program wrong.

rbanffy 13y ago
So, what is the correct way to open a file in such way you can still read (or write it) it if another process moves/renames/deletes it? Are you implying everyone who ever wrote an installer that can't install something without a reboot lacks proper understanding of how to open files?