Windows File Locking Issue: Does This Defect Come from Windows Core or NTFS?

It is common for us to get this kind of error in Windows:

• Open the command prompt, and then cd to a certain folder.
• During that time we will not be able to rename nor delete that particular folder.

File locking is acceptable when it is implemented at userspace.

However, when it is hard-coded inside the core OS, it is a disaster.

Viruses and any kind of userspace programs can exclusively take over the access on any files and any folders.

The elevated privileges like Administrator, Service, System, TrustedInstaller, etc; are meaningless as they are not able to break the lock.

As a result, Windows Updates also require many many reboot in order to complete its tasks.

Ironically, if the PC or laptop is secured with BIOS password during booting, users are encouraged to remove the password in order to allow the Windows to reboot without having to baby sit in front of the PC during the update (in other words, the PC has to operate under unsecured environment for the sake of Windows update)

Last year, a Microsoft fan came to me and argued that the file locking was caused by NTFS, not Windows.

So, this is to prove that the file locking is truely design defect on the Windows core OS level, not its filesystem:

(codes are written in C#, and can be compiled with any versions of Visual Studio)

using System;
using System.IO;

namespace ConsoleApplication1
{
    class Program
    {
        static string tempfilename = "test.xml";
        static void Main(string[] args)
        {
            Console.WriteLine("This program will test the defective by design on Microsoft products");
            Console.WriteLine("Press any key to start.");
            Console.ReadKey();
            Console.WriteLine("Executing file reading... (press ctrl-c to stop)");

            try { File.WriteAllText(tempfilename, "Defective by Design"); } 
            catch (Exception e) { Console.WriteLine(e.Message); }

            TestFileLocking();
            Console.WriteLine("Completed, press any key to exit.");
            Console.ReadKey();
            
        }
        static void TestFileLocking()
        {
            long i = 0;
            while (i < 100000000)
            {
                try
                {
                    using (FileStream f = File.Open(tempfilename, FileMode.Open, FileAccess.Read, FileShare.None)) {}
                }
                catch (Exception e)
                {
                    Console.WriteLine(string.Format("Defective by design found on iteration {0}: {1}", i, e.Message));
                }
                finally { i++; }
            }
        }
    }
}

With Windows, it is clearly shown that the two programs will result errors when they both are running at the same time, accessing the same file:

However, when the programs are executed in Linux (with mono runtime), the two programs run flawlessly in parallel even they are executed directly from NTFS mount point: