Если исполняемый код в файле должен быть заблокирован или нет, это проектное решение, и MS просто решила заблокировать, потому что на практике у него есть явные преимущества: таким образом, вам не нужно знать, какой код в какой версии используется какое приложение. Это основная проблема с поведением Linux по умолчанию, которое просто игнорируется большинством людей. При замене общесистемных библиотек вы не можете легко узнать, какие приложения используют код таких библиотек. В большинстве случаев лучшее, что вы можете получить, это то, что менеджер пакетов знает некоторых пользователей этих библиотек и перезапускает их. Но это работает только для общего и хорошо знаю такие вещи, как, может быть, Postgres и его libs или что-то подобное. Более интересные сценарии, если вы разрабатываете свое собственное приложение для некоторых сторонних библиотек, и они заменяются, потому что в большинстве случаев менеджер пакетов просто не знает ваше приложение. И это не только проблема нативного кода C или чего-то подобного, это может случиться практически со всем: просто используйте httpd с mod_perl и некоторыми библиотеками Perl, установленными с помощью менеджера пакетов, и позвольте менеджеру пакетов обновить эти Perl-библиотеки по любой причине. Он не перезапустит ваш httpd просто потому, что не знает зависимостей. Существует множество примеров, подобных этому, просто потому, что любой файл может потенциально содержать код, используемый в памяти любой средой выполнения, например, Java, Python и все такое.
Так что есть веская причина полагать, что блокировка файлов по умолчанию может быть хорошим выбором. Однако вам не нужно соглашаться с этими причинами.
Так что же сделал MS? Они просто создали API, который дает вызывающему приложению возможность решить, должны ли файлы быть заблокированы или нет, но они решили, что значением этого API по умолчанию является предоставление эксклюзивной блокировки первому вызывающему приложению. Посмотрите на API вокруг CreateFile и его аргумента dwShareMode. По этой причине вы не сможете удалить файлы, используемые каким-либо приложением, оно просто не заботится о вашем сценарии использования, использует значения по умолчанию и поэтому получает эксклюзивную блокировку Windows для файла.
Пожалуйста, не верьте, что люди, рассказывающие вам что-то о Windows, не используют ссылки на РУЧКИ или не поддерживают жесткие ссылки или что-то подобное, что совершенно неправильно. Почти каждый API, использующий HANDLE, документирует свое поведение в отношении подсчета ссылок, и вы можете легко прочитать практически в любой статье о NTFS, что он на самом деле поддерживает Hardlinks и всегда делал это. Начиная с Windows Vista, она также поддерживает Symlinks, а поддержка Hardlinks была улучшена благодаря предоставлению API для чтения всех из них для данного файла и т. Д.
Кроме того, вы можете просто захотеть взглянуть на структуры, используемые для описания файла, например. Ext4 по сравнению с NTFS , которые имеют много общего. Оба работают с концепцией экстентов, которая отделяет данные от таких атрибутов, как имя файла, а inode - это просто еще одно имя для более старой, но схожей концепции. Даже Википедия перечисляет обе файловые системы в своей статье .
Действительно много FUD вокруг блокировки файлов в Windows по сравнению с другими ОС в сети, как и в случае дефрагментации. Некоторые из этих FUD можно исключить, просто прочитав немного в Википедии .