The shrinking role of ETXTBSY

Posted Aug 28, 2021 18:38 UTC (Sat) by gnu_lorien (subscriber, #44036)
In reply to: The shrinking role of ETXTBSY by evgeny
Parent article: The shrinking role of ETXTBSY

"I feel like living in a parallel universe..."

I had the same feeling when reading this article.

I had an experience in a university class around 2006 where the professor claimed that you couldn't overwrite in-use files. I used Gentoo at the time and had never needed to shut down anything to recompile and update my system. The professor insisted this could happen but I couldn't find any scenario from the userspace tools I had available where I couldn't update in-use files.

I've also worked at companies that do cross-platform work for at least 15 years. It's a regular occurrence that things break for the Windows toolchain that don't break for GNU/Linux toolchain because Linux toolchains will happily update in-use binaries. It's one of the things I consider a huge misfeature of Windows that you have to go hunting down whoever is locking a file in order to finish a build. From a user perspective I would be shocked and annoyed if I started seeing ETXTBSY show up. I say good riddance.

The shrinking role of ETXTBSY

Posted Aug 30, 2021 21:20 UTC (Mon) by dancol (guest, #142293) [Link] (2 responses)

No, the Windows way to do things is the right one. You shouldn't be able to mess up a running program by mucking with its binary from underneath. On Windows, you can *move* the old file out of the way and then create a new file, which is what you should be doing on a Unix system too. Windows just enforces good hygiene.

The shrinking role of ETXTBSY

Posted Aug 31, 2021 4:33 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

You can rewrite the running file on Windows. You can't truncate or delete it, though.

This has more to do with the way the memory mapping is managed on Windows than with anything else.

The shrinking role of ETXTBSY

Posted Aug 31, 2021 12:59 UTC (Tue) by Wol (subscriber, #4433) [Link]

Pr1mos added the ability to rename an open file.

Dunno exactly how it worked, but it was something like the - if the linker hit an open file - it knew the magic sauce to rename it to move it out the way, then write a new one.

Same idea as *nix's ability to delete an open file then put a new one in its place - anything which has the old file open will continue to use that until it closes it.

Cheers,
Wol