4 ms·

One of the cause is that Windows by default does not allow you to remove or replace opened files. So to update anything you have to close all applications holdi

One of the cause is that Windows by default does not allow you to remove or replace opened files. So to update anything you have to close all applications holding an handle to it.

spatulon 8y ago
The fact that FILE_SHARE_DELETE has to be explicitly specified in calls to CreateFile, and that the file APIs in most languages don't use it or allow it to be specified, has to be one of the top three annoyances I have in using Windows as my primary development machine. There's a parallel universe in which FILE_SHARE_DELETE is opt-out, not opt-in, and Windows is a far more pleasant OS in that universe. My other two top annoyances, for anyone curious, are the appalling filesystem performance and the high process-creation overhead.
AnonymousPlanet 8y ago
The many lockdowns on opened files (even just reading) is one of biggest design flaws in Windows and has cost me many hours dealing with it. It makes a lot of things needlessly complicated: from updates over file based backups to sometimes even just reading a fscking logfile or config file.
- selimnairb 8y ago
  Yes, pessimistic file locking is a fatal design flaw in Windows. Where did they get this idea, VMS? What problems is it meant to solve? Unixen seem to get along fine without it.
  - pwg 8y ago
    I too would love to see something detailing the rationale for their choice of file locking defaults. If one could request a Raymond Chen insider explanation blog post, this one would be on my list of "why did they pick that default?".
    - nayuki 8y ago
      https://blogs.msdn.microsoft.com/larryosterman/2004/05/13/why-is-it-file_share_read-and-file_share_write-anyway/ https://blogs.msdn.microsoft.com/larryosterman/2004/05/13/wh... ; https://blogs.msdn.microsoft.com/oldnewthing/20071109-00/?p=24553 https://blogs.msdn.microsoft.com/oldnewthing/20071109-00/?p=...
  - forapurpose 8y ago
    > pessimistic file locking is a fatal design flaw in Windows. ... What problems is it meant to solve? How else do you prevent people from overwriting each other's changes to the same data? Whether the lock is at the file level, field level, etc., how else do you manage collisions? It seems so obvious that perhaps I misunderstand your question.
    - corrigible 8y ago
      ... versioning with NTFS ADS?
      - AnonymousPlanet 8y ago
        Oh dear, the next "let's squeeze some more arbitrary complexity into a thing that should be simple" fuckup is supposed to be a solution? One has to be a horribly inexperienced engineer not to see how ADS is a very bad idea.
    - mortehu 8y ago
      You can't write to a running executable on Linux either, but you can remove it and create a new file with the same name (optionally atomically with a rename). The old file keeps existing until it's closed. This allows running programs to be updated.
buckminster 8y ago
In many situations - including DLLs - you can rename the open file and create a new one with the original name.
int_19h 8y ago
It does allow you to remove them; the problem is that the removal will be pending until the last open handle to that file is closed. The file itself is in a weird suspended state whereby anyone who had an open handle is not disrupted, but attempts to create another handle to that file will fail. However, Windows does allow you to rename such files. So you can rename an existing file to some random name somewhere in %TEMP%, and then put a new file with the same name in its place.
MrStonedOne 8y ago
That's no excuse because there exists easy workarounds. From my understanding with how the winsxs store works, almost every system binary is really a hidden symlink to the right binary in winsxs (with some having different cpu optimizations). One of the cool things about symlinks is handles don't hold on them, they just hold on to the target, so you can change a symlink target without interrupting or getting blocked by handles that have that symlink open. Windows update could put all the new binaries in to new winsxs loctions then just swap over all of the symlinks on next boot. I know this works because I use it to deploy updates to a running game server binary so that the next time it restarts itself on round end it's using the new binary. We also update the loaded dlls it uses this way.
huhtenberg 8y ago
It's certainly not the cause. As another person said, you can rename opened files and then deal with deleting them separately.

One of the cause is that Windows by default does not allow you to remove or replace opened files. So to update anything you have to close all applications holding an handle to it.

spatulon 8y ago

The fact that FILE_SHARE_DELETE has to be explicitly specified in calls to CreateFile, and that the file APIs in most languages don't use it or allow it to be specified, has to be one of the top three annoyances I have in using Windows as my primary development machine. There's a parallel universe in which FILE_SHARE_DELETE is opt-out, not opt-in, and Windows is a far more pleasant OS in that universe. My other two top annoyances, for anyone curious, are the appalling filesystem performance and the high process-creation overhead.

AnonymousPlanet 8y ago

The many lockdowns on opened files (even just reading) is one of biggest design flaws in Windows and has cost me many hours dealing with it. It makes a lot of things needlessly complicated: from updates over file based backups to sometimes even just reading a fscking logfile or config file.

selimnairb 8y ago
Yes, pessimistic file locking is a fatal design flaw in Windows. Where did they get this idea, VMS? What problems is it meant to solve? Unixen seem to get along fine without it.
- pwg 8y ago
  I too would love to see something detailing the rationale for their choice of file locking defaults. If one could request a Raymond Chen insider explanation blog post, this one would be on my list of "why did they pick that default?".
  - nayuki 8y ago
    https://blogs.msdn.microsoft.com/larryosterman/2004/05/13/why-is-it-file_share_read-and-file_share_write-anyway/ https://blogs.msdn.microsoft.com/larryosterman/2004/05/13/wh... ; https://blogs.msdn.microsoft.com/oldnewthing/20071109-00/?p=24553 https://blogs.msdn.microsoft.com/oldnewthing/20071109-00/?p=...
- forapurpose 8y ago
  > pessimistic file locking is a fatal design flaw in Windows. ... What problems is it meant to solve? How else do you prevent people from overwriting each other's changes to the same data? Whether the lock is at the file level, field level, etc., how else do you manage collisions? It seems so obvious that perhaps I misunderstand your question.
  - corrigible 8y ago
    ... versioning with NTFS ADS?
    - AnonymousPlanet 8y ago
      Oh dear, the next "let's squeeze some more arbitrary complexity into a thing that should be simple" fuckup is supposed to be a solution? One has to be a horribly inexperienced engineer not to see how ADS is a very bad idea.
  - mortehu 8y ago
    You can't write to a running executable on Linux either, but you can remove it and create a new file with the same name (optionally atomically with a rename). The old file keeps existing until it's closed. This allows running programs to be updated.

buckminster 8y ago

In many situations - including DLLs - you can rename the open file and create a new one with the original name.

int_19h 8y ago

It does allow you to remove them; the problem is that the removal will be pending until the last open handle to that file is closed. The file itself is in a weird suspended state whereby anyone who had an open handle is not disrupted, but attempts to create another handle to that file will fail. However, Windows does allow you to rename such files. So you can rename an existing file to some random name somewhere in %TEMP%, and then put a new file with the same name in its place.

MrStonedOne 8y ago

That's no excuse because there exists easy workarounds. From my understanding with how the winsxs store works, almost every system binary is really a hidden symlink to the right binary in winsxs (with some having different cpu optimizations). One of the cool things about symlinks is handles don't hold on them, they just hold on to the target, so you can change a symlink target without interrupting or getting blocked by handles that have that symlink open. Windows update could put all the new binaries in to new winsxs loctions then just swap over all of the symlinks on next boot. I know this works because I use it to deploy updates to a running game server binary so that the next time it restarts itself on round end it's using the new binary. We also update the loaded dlls it uses this way.

huhtenberg 8y ago

It's certainly not the cause. As another person said, you can rename opened files and then deal with deleting them separately.