4 ms·
If memory serves, Microsoft cannot actually do it, due to differences in file system semantics. In Windows, it's not possible to replace a file that's in use.
by IsmaOlvey 10y ago
If memory serves, Microsoft cannot actually do it, due to differences in file system semantics. In Windows, it's not possible to replace a file that's in use.
- notalaser 10y agoUnfortunately, the last time I had to do system-level Windows programming was such a long time that all I remember are a bunch of things starting with hwndsomethingsomething, so I certainly don't remember if this is the case, nor the specifics (if I ever knew them, I was very young and therefore very stupid at the time). However, the opposite problem - that of (thread-safely) ensuring that you're not stepping on another process' file when you're writing, wiping or moving it - is pretty tedious under Unix. The only way to do it reliably - that I know of - is via flock, which is opt-in and therefore not always an option (e.g. the other process is a third-party application that doesn't lock its files), and doesn't work on remote filesystems There is no design decision without at least one compromise hanging on its tail.
- JdeBP 10y agoYour memory is serving you incorrectly. * https://news.ycombinator.com/item?id=11415366 https://news.ycombinator.com/item?id=11415366
- IsmaOlvey 10y agoUnlinking and replacing are not the same thing.
- throwawayish 10y agoDLLs and other components installed system-wide are almost never the same file: Updates install new versions of most DLLs into the SxS system and compatible applications load newer versions when they are restarted.
- digi_owl 10y agoUnless they bring their own version, something that has been a issue at least once.