Почему я не могу изменить используемые файлы в Windows, как могу в Linux и OS X?
Когда вы используете Linux и OS X, операционная система не помешает вам удалить файл, который используется в настоящее время, но в Windows вам будет явно запрещено делать это. Что дает? Почему вы можете редактировать и удалять используемые файлы в Unix-системах, но не в Windows?
Сегодняшняя сессия вопросов и ответов пришла к нам благодаря SuperUser - подразделению Stack Exchange, группе веб-сайтов вопросов и ответов, управляемой сообществом..
Вопрос
Читатель SuperUser the.midget хочет знать, почему Linux и Windows по-разному относятся к используемым файлам:
С тех пор, как я начал использовать Linux, меня озадачило то, что он позволяет вам изменять имя файла или даже удалять его во время чтения. Например, как я случайно попытался удалить видео во время его воспроизведения. Мне это удалось, и я был удивлен, узнав, что вы можете изменить практически все в файле, не обращая внимания, используется ли он в данный момент или нет.
Так что происходит за кулисами и мешает ему бесполезно удалять вещи в Windows, как он может в Linux?
Ответ
Участники SuperUser пролили некоторый свет на ситуацию с виджетом. Изумленный пишет:
Каждый раз, когда вы открываете или запускаете файл в Windows, Windows блокирует файл на месте (это упрощение, но обычно это так.) Файл, заблокированный процессом, не может быть удален, пока этот процесс не освободит его. Вот почему всякий раз, когда Windows нужно обновить себя, вам нужна перезагрузка, чтобы она вступила в силу.
С другой стороны, Unix-подобные операционные системы, такие как Linux и Mac OS X, блокируют не файл, а базовые сектора диска. Это может показаться тривиальным отличием, но это означает, что запись файла в оглавлении файловой системы может быть удалена, не мешая любой программе, в которой уже открыт файл. Таким образом, вы можете удалить файл, когда он все еще выполняется или иным образом используется, и он будет продолжать существовать на диске, пока какой-то процесс имеет открытый дескриптор для него, даже если его запись в таблице файлов отсутствует.
Дэвид Шварц расширяет эту идею и подчеркивает, как вещи должны быть в идеале и как они на практике:
В Windows по умолчанию установлена автоматическая обязательная блокировка файлов. В UNIX по умолчанию используется ручная кооперативная блокировка файлов. В обоих случаях значения по умолчанию могут быть переопределены, но в обоих случаях они обычно не.
Большая часть старого кода Windows использует API C / C ++ (функции, такие как fopen), а не нативный API (функции, такие как CreateFile). API C / C ++ не позволяет указать, как будет работать обязательная блокировка, поэтому вы получите значения по умолчанию. «Режим обмена» по умолчанию обычно запрещает «конфликтующие» операции. Если вы открываете файл для записи, считается, что запись конфликтует, даже если вы никогда не выполняете запись в файл. То же самое для переименований.
И вот где это становится хуже. Кроме открытия для чтения или записи, API C / C ++ не предоставляет способа указать, что вы собираетесь делать с файлом. Поэтому API должен предполагать, что вы собираетесь выполнять какие-либо законные операции. Поскольку блокировка является обязательной, в открытии, которое разрешает конфликтующую операцию, будет отказано, даже если код никогда не предназначался для выполнения конфликтующей операции, а просто открывал файл для другой цели..
Таким образом, если код использует API C / C ++ или использует нативный API, не задумываясь об этих проблемах, он будет предотвращать создание максимального набора возможных операций для каждого файла, который они открывают, и не сможет открыть файл, если только не будут выполнены все возможные операции. может выступать на нем после вскрытия не конфликтует.
По моему мнению, метод Windows работал бы намного лучше, чем метод UNIX, если бы каждая программа выбирала свои режимы общего доступа и открытые режимы, мудро и разумно обрабатывая случаи сбоев. Однако метод UNIX работает лучше, если код не задумывается над этими проблемами. К сожалению, базовый API C / C ++ плохо отображается на файловый API Windows таким образом, что обрабатывает режимы совместного использования и конфликты открываются хорошо. Таким образом, чистый результат немного грязный.
Вот и все: два разных подхода к обработке файлов дают два разных результата.
Есть что добавить к объяснению? Звук выключен в комментариях. Хотите узнать больше ответов от других технически подкованных пользователей Stack Exchange? Ознакомьтесь с полным обсуждением здесь.
