Почему я не могу изменить имя файла, который читается в Windows, как я могу это сделать в Linux / Mac?


23

Одна из вещей, которая озадачила меня с тех пор, как я начал использовать Linux, это то, что он позволяет вам менять имя файла или даже удалять его во время чтения. Например, как я случайно попытался удалить видео во время его воспроизведения. Мне это удалось, и я был удивлен, узнав, что вы можете изменить что угодно в файле, не обращая внимания, используется ли он в данный момент или нет.


2
Переименование заблокированного файла не является проблемой в Windows. Как правило, удаление заключается в том, что есть несколько программ, которые открывают файл с включенной опцией FILE_SHARE_DELETE.
Ганс Пассант

Вы на самом деле не удалили его, вы просто удалили его из каталога, в котором он находился. Файл все еще существует, он может просто не иметь никакого имени в файловой системе. (Хотя у него все еще есть имя в /procфайловой системе через программу, в которой оно открыто.) Файл может быть действительно удален, только если на него не осталось ссылок, и это происходит автоматически.
Дэвид Шварц

Ответы:


36

Каждый раз, когда вы открываете или запускаете файл в Windows, Windows блокирует файл на месте (это упрощение, но обычно это так.) Файл, заблокированный процессом, не может быть удален, пока этот процесс не освободит его. Вот почему всякий раз, когда Windows должна обновлять себя, вам требуется перезагрузка, чтобы она вступила в силу.

С другой стороны, Unix-подобные операционные системы, такие как Linux и Mac OS X, блокируют не файл, а базовые сектора диска. Это может показаться тривиальным отличием, но это означает, что запись файла в оглавлении файловой системы может быть удалена, не мешая любой программе, в которой уже открыт файл. Таким образом, вы можете удалить файл, пока он еще выполняется или используется иным образом, и он будет продолжать существовать на диске, пока какой-то процесс имеет открытый дескриптор для него, даже если его запись в таблице файлов отсутствует.


2
Спасибо за этот ответ. Это объясняет мне разницу намного больше. Это также помогает объяснить, почему загрузка больших файлов / видео не требует огромного количества оперативной памяти. В противном случае воспроизведение одного большого видео может затормозить всю вашу систему.
Джерри Саравиа

4
Если вы удалили файл, который использовался, и хотели вернуть его в Linux, вы можете найти запись файла в / proc, как описано в этом вопросе .
Кен Блум

2
Это отчасти обобщение - не все обновления Windows в настоящее время (на Windows 7) требуют перезагрузки, и я много сделал для Linux, что и было.
Алан Б

10

В Windows по умолчанию установлена ​​автоматическая обязательная блокировка файлов. В UNIX по умолчанию используется ручная кооперативная блокировка файлов. В обоих случаях значения по умолчанию могут быть переопределены, но в обоих случаях обычно нет.

Большая часть старого кода Windows использует API C / C ++ (например, функции fopen), а не нативный API (функции вроде CreateFile). API C / C ++ не дает возможности указать, как будет работать обязательная блокировка, поэтому вы получаете значения по умолчанию. «Режим совместного использования» по умолчанию запрещает «конфликтующие» операции. Если вы открываете файл для записи, запись считается конфликтной, даже если вы никогда не записываете файл. То же самое для переименований.

И вот где это становится хуже. Кроме открытия для чтения или записи, API C / C ++ не предоставляет способа указать, что вы собираетесь делать с файлом. Поэтому API должен предполагать, что вы собираетесь выполнять какие-либо законные операции. Поскольку блокировка является обязательной, в операции open, разрешающей конфликтующую операцию, будет отказано, даже если код никогда не предназначался для выполнения конфликтующей операции, а просто открывал файл для другой цели.

Таким образом, если код использует API C / C ++ или использует нативный API, не задумываясь об этих проблемах, он в конечном итоге будет препятствовать максимальному набору возможных операций для каждого файла, который они открывают, и не сможет открыть файл, если только не будут выполнены все возможные операции может выступать на нем, когда открыт, не конфликтует.

На мой взгляд, метод Windows работал бы намного лучше, чем метод UNIX, если бы каждая программа выбирала свои режимы общего доступа и открытые режимы, мудро и разумно обрабатывая случаи сбоев. Однако метод UNIX работает лучше, если код не задумывается над этими проблемами. К сожалению, базовый API C / C ++ плохо отображается на файловый API Windows таким образом, что обрабатывает режимы совместного использования и конфликты открываются хорошо. Таким образом, чистый результат немного грязный.


0

Это очень интересный вопрос, и он заставил меня задуматься над реальным ответом. Я надеюсь, что другие могут предоставить резервную копию здесь.

Я использую как Windows, так и Linux и тоже это заметил. Я также пользователь vim. Vim прочитает текстовый файл в «буфер» или в ОЗУ, а затем не коснется реального файла, пока вы не сохраните его. Linux может выполнять такие действия со всеми файлами.

Возьмем, к примеру, ваше видео, оно читает все видео, если это возможно, в ОЗУ, а затем у вас есть копия видео, которая легко доступна, доступна для поиска и имеет возможность перехода. Если файл слишком большой, то у вас могут возникнуть проблемы, потому что Linux может не прочитать все видео, возможно, просто большой кусок. Когда ваш проигрыватель доберется до конца буферизованного видео, он попытается снова прочитать файл. Если вы удалили видео, то это отстой для вас.

В некоторых случаях Windows является гораздо более «безопасной» ОС, поскольку она не позволяет вам этого делать. Он может буферизовать файлы так же, как это делает Linux, но также добавляет блокировку файлов, чтобы вы или другие программы не могли изменять файлы, над которыми вы работаете или просматриваете. Это помогает сохранить файл в целости и не дает вам или другим программам перезаписывать изменения друг друга.


Вы не можете на самом деле удалить его. Просто переместите его и переименуйте.
Даниэль Бек

2
Вы можете 'rm' это. Это достаточно близко, чтобы удалить его.
Крис Мур
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.