Я заметил, что когда файл выполняется в Windows (.exe или .dll), он заблокирован и не может быть удален, перемещен или изменен.
Linux, с другой стороны, не блокирует выполнение файлов, и вы можете их удалять, перемещать или изменять.
Почему Windows блокируется, когда Linux не работает? Есть ли преимущество в блокировке?
Linux имеет механизм подсчета ссылок, поэтому вы можете удалить файл во время его выполнения, и он будет продолжать существовать до тех пор, пока какой-то процесс (который ранее открыл его) имеет для него открытый дескриптор. Запись каталога для файла удаляется при его удалении, поэтому его нельзя открыть больше, но процессы, уже использующие этот файл, все еще могут использовать его. После завершения всех процессов, использующих этот файл, файл будет удален автоматически.
Windows не имеет этой возможности, поэтому принудительно блокировать файл до тех пор, пока все процессы, выполненные из него, не будут завершены.
Я считаю, что поведение Linux предпочтительнее. Вероятно, есть некоторые глубокие архитектурные причины, но главная (и простая) причина, которую я считаю наиболее привлекательной, - это то, что в Windows иногда вы не можете удалить файл, вы не знаете, почему, и все, что вы знаете, это то, что какой-то процесс хранит его в использовать. В Linux это никогда не происходит.
Насколько я знаю, linux блокирует исполняемые файлы, когда они работают, однако он блокирует inode. Это означает, что вы можете удалить "файл", но inode все еще находится в файловой системе, нетронутой, и все, что вы действительно удалили, это ссылка.
Unix-программы постоянно используют этот способ мышления о файловой системе, создают временный файл, открывают его, удаляют имя. Ваш файл все еще существует, но имя освобождается для других, и никто не может его увидеть.
Linux блокирует файлы. Если вы попытаетесь перезаписать исполняемый файл, вы получите "ETXTBUSY" (текстовый файл занят). Однако вы можете удалить файл, и ядро удалит файл, когда последняя ссылка на него будет удалена. (Если машина не была полностью отключена, эти файлы являются причиной того, что сообщения "Deleted inode имели нулевые d-time" при проверке файловой системы, они не были полностью удалены, поскольку в текущем процессе была ссылка на них, и теперь они есть.)
Это имеет некоторые основные преимущества, вы можете обновить выполняемый процесс, удалив исполняемый файл, заменив его, а затем перезапустив процесс. Даже init можно обновить следующим образом: замените исполняемый файл и отправьте ему сигнал, и он будет сам re-exec(), не требуя перезагрузки. (Это обычно выполняется автоматически вашей системой управления пакетами как часть обновления)
В окнах замена файла, который используется, является серьезной проблемой, обычно требуется перезагрузка, чтобы убедиться, что процессы не запущены.
Возникают некоторые проблемы, например, если у вас очень большой файл журнала, и вы его удаляете, но забудьте сообщить, что процесс, который регистрировался в этом файле, для повторного открытия файла, он будет содержать ссылку, и вы "Интересно, почему ваш диск внезапно не получил намного больше свободного места.
Вы также можете использовать этот трюк в Linux для временных файлов. откройте файл, удалите его, затем продолжайте использовать файл. Когда ваш процесс завершается (независимо от причины - даже сбой питания), файл будет удален.
Программы, такие как lsof и fuser (или просто прокручивание в /proc//fd ), могут показать вам, какие процессы открывают файлы, которые больше не имеют имени.
Я думаю, что linux/unix не использует одну и ту же механику блокировки, потому что они построены с нуля как многопользовательская система, что предполагает возможность использования несколькими пользователями одного и того же файла, возможно, даже для разных целей.
Есть ли преимущество в блокировке? Ну, это могло бы уменьшить количество указателей, которые ОС должно было бы управлять, но теперь через несколько дней сумма сбережений довольно незначительна. Самое большое преимущество, которое я могу придумать для блокировки, заключается в следующем: вы сохраняете некоторую двусмысленность, видимую пользователем. Если пользователь a работает с двоичным файлом, а пользователь b удаляет его, тогда фактический файл должен придерживаться, пока процесс пользователя A не завершится. Тем не менее, если пользователь B или другие пользователи смотрят на файловую систему для него, они не смогут его найти, но он будет продолжать занимать место. На самом деле это не вызывает большого беспокойства.
Я думаю, что в большей степени это вопрос о обратной совместимости с файловыми системами окон.
Я думаю, вы слишком абсолютны в отношении Windows. Как правило, он не выделяет пространство подкачки для части кода исполняемого файла. Вместо этого он удерживает блокировку на excutable и DLL. Если отброшенные кодовые страницы нужны снова, они просто перезагружаются. Но с /SWAPRUN эти страницы хранятся в свопе. Это используется для исполняемых файлов на компакт-дисках или сетевых дисках. Следовательно, окнам не нужно блокировать эти файлы.
Для .NET просмотрите Теневое копирование.
Если исполняемый код в файле должен быть заблокирован или нет, это решение по дизайну, и MS просто решила заблокировать его, поскольку на практике он имеет очевидные преимущества: таким образом вам не нужно знать, какой код, в какой версии используется какое приложение. Это серьезная проблема с поведением Linux по умолчанию, которое просто игнорируется большинством людей. Если заменить системные библиотеки, вы не можете легко узнать, какие приложения используют код таких библиотек, в большинстве случаев лучшее, что вы можете получить, это то, что менеджер пакетов знает некоторых пользователей этих библиотек и перезапускает их. Но это работает только для общих и хорошо известных вещей, таких как, может быть, Postgres и его библиотеки или такие. Более интересные сценарии - если вы разрабатываете собственное приложение против некоторых сторонних библиотек, а те заменяются, потому что большую часть времени менеджер пакетов просто не знает ваше приложение. И это не только проблема родного кода C или такого, это может произойти почти со всем: просто используйте httpd с mod_perl и некоторые Perl-библиотеки, установленные с помощью диспетчера пакетов, и пусть менеджер пакетов обновляет эти Perl-библиотеки по какой-либо причине. Он не перезапустит ваш httpd, просто потому, что он не знает зависимостей. Есть много примеров, подобных этому, просто потому, что любой файл может потенциально содержать код, используемый в памяти любой средой выполнения, думать о Java, Python и обо всех таких вещах.
Таким образом, есть веская причина иметь мнение, что блокировка файлов по умолчанию может быть хорошим выбором. Однако вам не нужно соглашаться с этими причинами.
Так что сделала MS? Они просто создали API, который дает вызывающему приложению возможность решить, должны ли файлы блокироваться или нет, но они решили, что значение по умолчанию этого API заключается в предоставлении эксклюзивной блокировки для первого вызывающего приложения. Посмотрите API на CreateFile и его аргумент dwShareMode. Именно по этой причине вы не сможете удалять файлы, используемые некоторыми приложениями, это просто не касается вашего варианта использования, использует значения по умолчанию и, следовательно, получает эксклюзивную блокировку Windows для файла.
Пожалуйста, не верьте, что люди рассказывают вам что-то о том, что Windows не использует ref counting на HANDLE или не поддерживает Hardlinks или что-то подобное, это совершенно неправильно. Почти каждый API, использующий HANDLEs, документирует свое поведение в отношении подсчета ссылок, и вы можете легко прочитать практически любую статью о NTFS, которая на деле поддерживает Hardlinks и всегда выполнялась, поскольку Windows Vista также поддерживает Symlinks, а поддержка Hardlinks улучшилось, предоставив API для прочитать все жесткие ссылки для данного файла и т.д.
Кроме того, вы можете просто захотеть взглянуть на структуры, используемые для описания файла, например. Ext4 по сравнению с NTFS, которые имеют много общего. Оба работают с концепцией экстентов, которая отделяет данные от таких атрибутов, как имя файла, и inodes - это просто другое имя для более старой, но аналогичной концепции. Даже Wikipedia перечисляет обе файловые системы в статье .
Там действительно много FUD вокруг блокировки файлов в Windows по сравнению с другими ОС в сети, как и дефрагментация.;-) Некоторые из этих FUD можно исключить, просто прочитав бит на Wikipedia.
Варианты NT имеют
openfiles
которая покажет, какие процессы имеют дескрипторы файлов. Однако для этого требуется включить глобальный флаг системы "сохранить список объектов"
openfiles/local/?
расскажет вам, как это сделать, а также, что это может быть связано с производительностью.
Исполняемые файлы постепенно отображаются в память при запуске. Это означает, что части исполняемого файла загружаются по мере необходимости. Если файл выгружается до отображения всех разделов, это может вызвать серьезную нестабильность.