Optional mandatory locking

Posted Dec 10, 2015 12:44 UTC (Thu) by jnareb (subscriber, #46500)
Parent article: Optional mandatory locking

File locking in MS Windows was for me on of bigger sources of frustrations with this operating system...

to post comments

Optional mandatory locking

Posted Dec 10, 2015 13:49 UTC (Thu) by philipstorry (subscriber, #45926) [Link] (1 responses)

Windows NT file locking is - AIUI - entirely down to the "Windows personality" running on top of the kernel. The kernel in Windows certainly used to support POSIX-style file operations, so didn't have to enforce locking. The original design of Windows NT allowed for these "personalities", which were originally called subsystems. There was a POSIX one, an OS/2 one, and Windows itself.
Both the other subsystems are dead these days, as Windows has focused more and more on just being Windows.

My understanding was that Windows file locking was more a decision taken for backwards compatibility more than anything else. They decided to enforce the old DOS-style file locking (that you had if you loaded SHARE.EXE) when they went multi-user, as it was the cleanest and clearest way to do so and have existing applications understand what was going on if a file was locked.

As Windows NT was multi-user, they then went further and baked that file locking in to the OS components.

Of course, in practice none of this matters, except when you're trying to explain to someone why Windows inevitably requires a restart after a software installation/update...

Optional mandatory locking

Posted Dec 15, 2015 16:56 UTC (Tue) by k8to (guest, #15413) [Link]

Or trying to write an application which shares data with other applications.

(Not a common case, but it comes up.)

Or more likely you're trying to port some Unix software that happens to do rename swizzling on open files.

But agreed the reboot-on-update is the most common.