> This model is not unique to Windows, rather most non POSIX OSes. You could also point out that the hardlink/ref-count concept is not unique to POSIX and is p

> This model is not unique to Windows, rather most non POSIX OSes. You could also point out that the hardlink/ref-count concept is not unique to POSIX and is present on Windows. https://msdn.microsoft.com/en-us/library/windows/desktop/aa363860(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... > Now replace the contents file being worked on or delete it, in the context of a multi-process application, that passes the name around via IPC. ... Sure... if you depend on passing filenames around, removing them is liable to cause problems. The system I mentioned before worked as well as it did for us, precisely because the filenames didn't matter that much. (We had enough design flexibility to design the system that way.) That said, we did run into minor issues with the Windows approach to file deletion. For performance reasons, we mapped many of our larger files into memory. Unfortunately, because we were running on the JVM, we didn't have a safe way to unmap the memory mapped files when we were done with them. (You have to wait for the buffer to be GC'ed, which is, of course, a non-deterministic process.) http://bugs.java.com/view_bug.do?bug_id=4724038 http://bugs.java.com/view_bug.do?bug_id=4724038 On Linux, this was fine because we didn't have to have the file unmapped to delete it. However, on our Windows workstations, this kept us from being able to reliably delete memory mapped files. This was mainly just a problem during development, so it wasn't worth finding a solution, but it was a bit frustrating.