Блокировка файла

редактировать

Блокировка файла - это механизм, ограничивающий доступ к компьютерному файлу или к области файл, позволяя только одному пользователю или процессу изменять или удалять его в определенное время и предотвращать чтение файла во время его изменения или удаления.

Системы реализуют блокировку для предотвращения классического сценария промежуточного обновления, который является типичным примером состояния гонки, путем принудительной сериализации процессов обновления в любой заданный файл. Следующий пример иллюстрирует проблему промежуточного обновления:

  1. Процесс A считывает запись о клиенте из файла, содержащего информацию об учетной записи, включая баланс счета и номер телефона клиента.
  2. Процесс Теперь B считывает ту же запись из того же файла, поэтому у него есть собственная копия.
  3. Процесс A изменяет баланс счета в своей копии записи о клиенте и записывает запись обратно в файл.
  4. Процесс B, который по-прежнему имеет исходное устаревшее значение баланса счета в своей копии записи клиента, обновляет баланс счета и записывает запись клиента обратно в файл.
  5. Процесс B теперь записал устаревшее значение account-balance в файл, что приводит к потере изменений, внесенных процессом A.

Большинство операционных систем поддерживают концепцию блокировки записи, что означает, что отдельные записи в любой данный файл может быть заблокирован, тем самым увеличивая количество одновременных процессов обновления. При обслуживании базы данных используется блокировка файлов, благодаря чему можно сериализовать доступ ко всему физическому файлу, лежащему в основе базы данных. Хотя это действительно предотвращает доступ к файлу любого другого процесса, он может быть более эффективным, чем индивидуальная блокировка большого количества областей в файле, путем устранения накладных расходов на получение и снятие каждой блокировки.

Плохое использование блокировок файлов, как и любой компьютер блокировка, может привести к снижению производительности или возникновению взаимоблокировок. Блокировка файлов также может относиться к дополнительной безопасности, применяемой пользователем компьютера с помощью безопасности Windows, разрешений NTFS или путем установки стороннего программного обеспечения для блокировки файлов.

Содержание
  • 1 В мэйнфреймах
  • 2 В Microsoft Windows
  • 3 В Unix-подобных системах
    • 3.1 Проблемы
    • 3.2 Проблемы с буферизованным вводом-выводом
  • 4 В Amiga OS
  • 5 Блокировка файлов
  • 6 Программное обеспечение разблокировки
  • 7 Системы контроля версий
  • 8 См. Также
  • 9 Ссылки
  • 10 Внешние ссылки
В мэйнфреймах

IBM впервые применила блокировку файлов в 1963 году для использования на мэйнфреймах, использующих OS / 360, где это называлось «исключительный контроль».

В Microsoft Windows

Microsoft Windows использует три различных механизма для управления доступом к общие файлы:

  1. с использованием элементов управления общим доступом, которые позволяют приложениям указывать общий доступ к файлу для чтения, записи или удаления
  2. , используя блокировки диапазона байтов для арбитража доступа на чтение и запись к регионам в пределах один файл
  3. файловыми системами Windows, запрещающими открывать исполняемые файлы для записи или удаления

Windows наследует семантику элементов управления общим доступом из системы MS-DOS, где совместное использование был представлен в MS-DOS 3.3. Таким образом, приложение должно явно разрешать совместное использование при открытии файла; в противном случае он имеет эксклюзивный доступ на чтение, запись и удаление к файлу до закрытия (разрешены другие типы доступа, например, для получения атрибутов файла).

Для файла, открытого с общим доступом, приложения могут затем использовать блокировку диапазона байтов для управления доступом к определенным областям файла. Такие блокировки диапазона байтов определяют область файла (смещение и длину) и тип блокировки (общая или исключительная). Обратите внимание, что в блокируемой области файла не обязательно должны быть данные внутри файла, и приложения иногда используют эту возможность для реализации своих функций.

Для приложений, которые используют чтение / запись файлов API в Windows, блокировки диапазона байтов применяются (также называемые обязательными блокировками) файловыми системами, которые выполняются в Windows. Для приложений, которые используют сопоставление файлов API в Windows, блокировки байтового диапазона не применяются (также называемые рекомендательными блокировками). Блокировка байтового диапазона может также иметь другие побочные эффекты в системе Windows. Например, механизм совместного использования файлов Windows обычно отключает кэширование файла на стороне клиента для всех клиентов, когда какой-либо клиент использует блокировку диапазона байтов. Клиент будет наблюдать более медленный доступ, потому что операции чтения и записи должны быть отправлены на сервер, где хранится файл.

Неправильная обработка ошибок в прикладной программе может привести к сценарию, когда файл заблокирован (либо с использованием «общего» доступа, либо с блокировкой файла с байтовым диапазоном) и не может быть доступен другим приложениям. В этом случае пользователь может восстановить доступ к файлу, вручную завершив работу неисправной программы. Обычно это делается с помощью утилиты диспетчера задач.

Параметр режима совместного использования (dwShareMode) функции CreateFile(используемой для открытия файлов) определяет совместное использование файлов. Можно указать режим совместного использования, чтобы разрешить общий доступ к файлу для чтения, записи или удаления, или любую их комбинацию. Последующие попытки открыть файл должны быть совместимы со всеми ранее предоставленными правами общего доступа к файлу. Когда файл закрывается, ограничения общего доступа корректируются, чтобы удалить ограничения, налагаемые открытием этого конкретного файла.

Тип блокировки байтового диапазона определяется параметром dwFlagsв функции LockFileEx, используемой для блокировки области файла. Также можно использовать функцию Windows API LockFile, которая устанавливает исключительную блокировку области файла.

Любой файл, содержащий исполняемый программный файл, который в данный момент запущен в компьютерной системе как программа (например, EXE , COM, DLL, CPL или другой формат двоичного программного файла) обычно блокируется самой операционной системой, что не позволяет любому приложению изменять или удалять его. Любая попытка сделать это будет отклонена из-за ошибки нарушения совместного доступа, несмотря на то, что файл программы не открывается ни одним приложением. Однако некоторый доступ все же разрешен. Например, файл работающего приложения можно переименовать или скопировать (прочитать) даже во время выполнения.

Приложения в Windows получают доступ к файлам с помощью дескрипторов файлов. Эти дескрипторы файлов можно просмотреть с помощью утилиты Process Explorer. Эту утилиту также можно использовать для принудительного закрытия дескрипторов без необходимости завершать удерживающее их приложение. Это может вызвать неопределенное поведение, поскольку программа получит неожиданную ошибку при использовании принудительно закрытого дескриптора и может даже работать с неожиданным файлом, поскольку номер дескриптора может быть повторно использован.

Microsoft Windows XP и В редакциях Server 2003 появилась возможность моментальных снимков тома (VSS) для NTFS, что позволяет программному обеспечению резервного копирования получать доступ к открытым файлам.>несмотря ни на какие эксклюзивные блокировки. Однако, если программное обеспечение не будет переписано специально для поддержки этой функции, моментальный снимок будет только согласованным с аварийным отказом, в то время как правильно поддерживаемые приложения могут помочь операционной системе в создании "транзакционно согласованных" моментальных снимков. Другое коммерческое программное обеспечение для доступа к заблокированным файлам в Windows включает и. Они работают путем установки собственных драйверов для доступа к файлам в режиме ядра.

В Unix-подобных системах

Unix-подобных операционных системах (включая Linux и Apple macOS ) обычно не блокируют автоматически открытые файлы. Несколько видов механизмов блокировки файлов доступны в различных версиях Unix, и многие операционные системы поддерживают более одного типа для совместимости. Самый распространенный механизм - fcntl . Два других таких механизма - это flock(2) и lockf (3) , которые могут быть отдельными или могут быть реализованы поверх fcntl. Хотя некоторые типы блокировок можно настроить как обязательные, блокировки файлов в Unix по умолчанию рекомендуются. Это означает, что взаимодействующие процессы могут использовать блокировки для координации доступа к файлу между собой, но не взаимодействующие процессы также могут игнорировать блокировки и обращаться к файлу любым способом по своему выбору. Другими словами, файловые блокировки блокируют только другие файловые хранилища, но не операции ввода-вывода.

Предлагаются два вида блокировок: разделяемые блокировки и эксклюзивные блокировки. В случае fcntlразличные виды блокировок могут применяться к разным разделам (диапазонам байтов) файла или ко всему файлу. Совместно используемые блокировки могут удерживаться несколькими процессами одновременно, но исключительная блокировка может удерживаться только одним процессом и не может сосуществовать с общей блокировкой. Чтобы получить разделяемую блокировку, процесс должен дождаться, пока ни один из процессов не будет удерживать эксклюзивные блокировки. Чтобы получить монопольную блокировку, процесс должен дождаться, пока ни один из процессов не установит блокировку любого типа. В отличие от блокировок, созданных fcntl, блокировки, созданные flock, сохраняются в forks, что делает их полезными при разветвлении серверов. Таким образом, более чем один процесс может удерживать монопольную блокировку одного и того же файла при условии, что эти процессы разделяют сыновние отношения, а монопольная блокировка изначально была создана в одном процессе перед дублированием в fork.

Shared блокировки иногда называют «блокировками чтения», а монопольные блокировки иногда называют «блокировками записи». Однако, поскольку блокировки в Unix рекомендуются, это не выполняется. Таким образом, для базы данных возможно использование концепции «совместно используемой записи» и «исключительной записи»; например, изменение поля на месте может быть разрешено при совместном доступе, тогда как сборка мусора и перезапись базы данных может потребовать монопольного доступа.

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

По этой причине некоторые Unix-подобные операционные системы также предлагают ограниченную поддержку обязательной блокировки. В таких системах файл, чей бит setgidустановлен, но чей бит выполнения группы отключен при открытии этого файла, будет подвергаться автоматической принудительной блокировке, если соответствующая файловая система поддерживает это. Однако нелокальные разделы NFS обычно игнорируют этот бит. Если файл подлежит обязательной блокировке, попытки чтения из области, которая заблокирована исключительной блокировкой, или записи в область, которая заблокирована общей или исключительной блокировкой, будут блокироваться до тех пор, пока блокировка не будет снята. Эта стратегия впервые зародилась в System V, и сегодня ее можно увидеть в операционных системах Solaris, HP-UX и Linux. Однако он не является частью POSIX и операционных систем, производных от BSD, таких как FreeBSD, OpenBSD, NetBSD и macOS от Apple. не поддерживаю это. Linux также поддерживает принудительную блокировку с помощью специального параметра -o mandдля монтирования файловой системы (mount (8) ), но он используется редко.

Некоторые Unix-подобные операционные системы предотвращают попытки открыть исполняемый файл работающей программы для записи; это третья форма блокировки, отличная от тех, которые предоставляются fcntlи flock.

Проблемы

Более одного процесса могут содержать эксклюзивный flockдля данного файла, если эксклюзивная блокировка была продублирована в более поздней вилке. Это упрощает кодирование для сетевых серверов и помогает предотвратить состояние гонки, но может сбивать с толку непосвященных.

Обязательные блокировки не влияют на системный вызов unlink. Следовательно, некоторые программы могут эффективно обходить обязательную блокировку. Стивенс и Раго (2005) заметили, что редактор edдействительно делал это.

Независимо от того, работают ли блокировки flockв сетевых файловых системах, таких как NFS <, и как 102>, зависит от реализации. В системах BSD вызовы flockдля файлового дескриптора, открытого для файла в разделе, смонтированном с помощью NFS, успешны no-ops. В Linux до 2.6.12 вызовы flockдля файлов NFS действовали только локально. Ядро 2.6.12 и выше реализуют вызовы flockдля файлов NFS с использованием блокировок байтового диапазона POSIX. Эти блокировки будут видны другим клиентам NFS, которые реализуют блокировки POSIX в стиле fcntl, но невидимы для тех, кто этого не делает.

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

Все блокировки fcntl, связанные с файлом для данного процесса, снимаются, когда какой-либо файловый дескриптор для этого файла закрывается этим процессом, даже если блокировка никогда не запрашивалась для этого файлового дескриптора. Кроме того, блокировки fcntlне наследуются дочерним процессом. Семантика закрытия fcntlособенно проблемна для приложений, которые вызывают библиотеки подпрограмм, которые могут обращаться к файлам. Ни одна из этих "ошибок" не возникает при использовании реальных блокировок в стиле flock.

Сохранение статуса блокировки дескрипторов открытых файлов, передаваемых другому процессу с использованием сокета домена Unix, зависит от реализации.

Проблемы буферизованного ввода-вывода

Один из источников сбоя блокировки возникает, когда буферизованный ввод-вывод имеет буферы, назначенные в локальной рабочей области пользователя, а не в пуле буферов операционной системы. freadи fwriteобычно используются для буферизованного ввода-вывода, и как только раздел файла будет прочитан, другая попытка чтения того же раздела, скорее всего, приведет к получению данных из локального буфера. Проблема в том, что другой пользователь, подключенный к тому же файлу, имеет свои собственные локальные буферы, и с ними происходит то же самое. fwriteданных, полученных из буфера с помощью fread, не будет получать данные из самого файла, и какой-то другой пользователь мог бы изменить его. Оба могут использовать flockдля монопольного доступа, что предотвращает одновременную запись, но поскольку операции чтения считываются из буфера, а не из самого файла, любые данные, измененные пользователем №1, могут быть потеряны пользователем №2 (более написано). Лучшее решение этой проблемы - использовать небуферизованный ввод-вывод (чтениеи запись) с flock, что также означает использование lseekвместо fseekи ftell. Конечно, вам придется внести изменения в параметры функции и возвращаемые результаты. Вообще говоря, буферизованный ввод-вывод небезопасен при использовании с общими файлами.

В Amiga OS

В Amiga OS блокировка файла (или каталога) может быть получена с помощью функции Lockdos.library). Блокировка может быть общей (другие процессы могут читать файл / каталог, но не могут изменять или удалять его) или монопольной, так что только процесс, успешно установивший блокировку, может получить доступ к объекту или изменить его. Замок находится на объекте в целом, а не на его части. Блокировка должна быть снята с помощью функции UnLock: в отличие от Unix, операционная система неявно не разблокирует объект при завершении процесса.

Блокировка файлов

Сценарии оболочки и другие программы часто используют стратегию, аналогичную использованию блокировки файлов: создание файлов блокировки, то есть файлов, содержимое которых не имеет значения (хотя часто можно найти идентификатор процесса держателя блокировки в файле), единственная цель которого - сигнализировать своим присутствием о том, что некоторый ресурс заблокирован. Файл блокировки часто является лучшим подходом, если управляемый ресурс вообще не является обычным файлом, поэтому использование методов блокировки файлов не применяется. Например, файл блокировки может управлять доступом к набору связанных ресурсов, например к нескольким различным файлам, каталогам, группе разделов диска или выбранному доступу к протоколам более высокого уровня, таким как серверы или соединения с базой данных.

При использовании файлов блокировки необходимо следить за тем, чтобы операции были атомарными. Чтобы получить блокировку, процесс должен убедиться, что файл блокировки не существует, а затем создать его, не допуская при этом его создания другим процессом. Для этого используются различные методы:

  • Использование команды lockfile(средство создания условного файла семафора, распространяемое в пакете procmail).
  • Системные вызовы, которые создают файл, но не удается, если файл уже существует. (Системные вызовы доступны из таких языков, как C или C ++, а сценарии оболочки могут использовать noclobber )
  • Использование команды mkdirи проверка кода выхода на предмет сбоя

Файлы блокировки часто именуются с префиксом тильды (~) перед именем файла, который они блокируют, или дубликатом полного имени файла с суффиксом .LCK. Если они блокируют ресурс кроме файла, они могут называться произвольно.

Некоторые продукты Mozilla (например, Firefox, Thunderbird, Sunbird) используют этот тип механизма блокировки файловых ресурсов (с использованием временного файла с именем "parent.lock".)

Программа разблокировки

Программа разблокировки - это утилита, используемая для определения того, какой процесс блокирует файл, а также отображает список процессов как выбор того, что делать с процессом (задача уничтожения, разблокировка и т. д.), а также список параметров файла, таких как удаление или переименование. В некоторых Unix-подобных системах такие утилиты, как fstatи lockfможно использовать для проверки ct состояние блокировки файла по процессу, по имени файла или по обоим.

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

Системы контроля версий

В системах контроля версий блокировка файлов используется для предотвращения одновременного изменения одной и той же версии файла двумя пользователями, а затем при сохранении перезапись вторым пользователем что изменил первый пользователь. Это реализуется путем пометки заблокированных файлов в файловой системе как предназначенные только для чтения. Пользователь, желающий изменить файл, выполняет операцию разблокировки (также называемую извлечением), и до тех пор, пока не будет выполнена операция возврата (сохранения) или блокировка не будет отменена, никому другому не разрешено разблокировать файл.

См. Также
Ссылки
Внешние ссылки
Последняя правка сделана 2021-05-20 03:42:01
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте