That edge case is certainly their official excuse.

Ultimately to determine the underlying root-cause you'd still need to dig this same information out, and all they've done is moved the starting line behind several walls. In essence adding extra work, without solving this edge case/issue.

Regardless of if the information is in the BSOD, Event Log, or only via WinDbg, understanding the information relies on the expertise of the person reviewing/contextualizing it. They've gone out of their way to make contextualizing it harder.

For example, to determine if it is a direct failure or an associative failure (e.g. RAM failing causing different BSODs in unrelated modules), you want that context to be obvious. But without the module being in the Event Logs, you're now loading up half a dozen MiniDumps in WinDbg to find that same very key information - which people may miss or fail to do.

What I am saying is: If we believe that excuse (which I don't), they've done absolutely nothing to address it and just made that same problem worse with their childish games.

On Linux you can delete all hardlinks to open files.

What you can't do is modify a file that's executing (program or library), then you get ETXTBSY.

Hard links are just pointers to the file. You can remove any or all of them independently of each other and the running program. In fact, IIRC there's a semi-common pattern where a program will deliberately create a file, open it, and then unlink it, which leaves it usable but anonymous and in a state that will always be garbage-collected when the program exits.

No, you can't rename a file in use, unless it is explicitly opened with a sharing flag (which most applications don't).

In windows the shadow copy facility is used to sneak files around when they are open. I remember using a utility called "hobocopy" (a sort of pun on the more famous robocopy) that provided a command line user interface around shadow copy to let you move locked files.

In my specific case it was to save youtube videos when it was still a flash player. the video would be cached in a file but that file would be inaccessible because it was "open" hobocopy to the rescue. On linux it would make then delete the file depending on the open file descriptor to keep it around. The way to save it was to relink another name onto the inode. I can't quite remember but on linux I think you could use a /proc entry to get that inode and on obsd I would use fstat to find it and fsdb to make the relink.

As a unix aficionado I despise windows open file locking with a passion. Sure I understand it is probably more correct, An open file could be in any sort of corrupted state the only safe thing to do is default to single access and locking. But it is far more respectful to the user to just let them grab it whenever they want to. corruption be dammed.