Работа  с файлами – ЧАСТЬ 3

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

Вы также можете явно запросить  создание еще одной резервной копии из буфера, даже если буфер был уже сохранен хотя бы раз. Если вы сохраните буфер с помощью C-u C-x C-s, записанная таким способом версия станет резервной, если вы сохраните буфер снова. C-u C-u C-x C-s сохраняет буфер, но сначала переносит старое содержимое файла в новый резервный файл. C-u C-u C-u C-x C-s делает и то, и другое: она создает резервную копию старого содержимого и готовится  сделать еще одну из вновь сохраненного содержимого, если вы сохраните буфер опять.

14.3.1.1  Одиночные или нумерованные резервные файлы

Если вы решили держать единственный  резервный файл (что принимается по умолчанию), то его имя составляется путем добавления ‘~’ к имени редактируемого  файла, таким образом, резервный файл для ‘eval.c’ назывался бы ‘eval.c~’.

Если вы захотите иметь серию пронумерованных  резервных файлов, то их имена создаются путем добавления ‘.~’,  номера и другой ‘~’ к исходному имени файла. Таким образом, резервные копии файла ‘eval.c’ будут называться ‘eval.c.~1~’, ‘eval.c.~2~’ и так далее, проходя через такие имена, как ‘eval.c.~259~’ и выше.

Если защита запрещает вам записывать  резервные файлы под обычными именами, то они записываются  как  ‘%backup%~’  в вашем начальном каталоге.   Может  существовать только один такой файл, поэтому доступна только резервная копия, сделанная самой последней.

Выбор  единственного   резервного файла или  нескольких  управляется переменной

version-control. Ее возможные значения:

t         Создавать нумерованные резервные файлы.

nil        Создавать нумерованные  резервные файлы для файлов,  которые  уже  имеют нумерованные файлы. Иначе создавать один резервный файл.

never         Никогда не создавать нумерованные  файлы, всегда делать одиночный резерв-

ный файл.

Вы можете  установить version-control локально в отдельном буфере,  для управления созданием резервных копий файла этого буфера.  Например, режим Rmail локально устанавливает version-control на never, чтобы быть уверенным, что для Rmail-файла существует только один резервный файл. См. Раздел 31.2.4 [Локальные переменные], с. 350.

Если вы установите  переменную среды VERSION_CONTROL,  чтобы указать различным утилитам GNU, что делать с резервными файлами, Emacs также  подчиняется ей, устанавливая соответственно  во время запуска переменную  Лиспа version-control.   Если значение этой переменной среды равно ‘t’ или ‘numbered’, то version-control становится равной t;  если это значение равно ‘nil’ или ‘existing’, то version-control становится nil; если это ‘never’ или ‘simple’,  то version-control устанавливается в значение never.

14.3.1.2  Автоматическое удаление  резервных файлов

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

Двумя  переменными, контролирующими  удаление, являются kept-old-versions  и kept-new-versions.  Их значения — это, соответственно, номер самой старой резервной копии файла (наименьший  номер), которая должна быть сохранена, и номер самой последней копии (наибольший номер), которая должна сохраняться каждый раз, когда создается новая копия.  Помните,  что эти значения используются сразу после того, как  создастся новая резервная копия; вновь созданная копия включается в счетчик kept-new-version. По умолчанию  обе переменные равны 2.

Если delete-old-versions не  равна nil,  то излишек средних версий уничтожается безропотно. Если же она nil, как по умолчанию, тогда вас спрашивают, должен ли быть уничтожен излишек промежуточных версий.

Команда Dired . (точка) также может быть использована для удаления старых версий.

См. Раздел 28.3 [Удаление в Dired], с. 291.

14.3.1.3  Копирование vs. переименование

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

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

Метод создания резервных  файлов также может затронуть владельцев и группы владельцев файлов. Если используется копирование, то они не изменяются.  Если используется переименование, то вы становитесь  владельцем файла, и устанавливается группа по умолчанию (различные операционные системы используют различные значения по умолчанию для группы).

Изменение владельца обычно является хорошей идеей, поскольку тогда всегда видно, кто последним редактировал файл. Кроме того, владельцы резервных копий показывают, кто  сделал эти версии.  Иногда существует файл, чей владелец  не должен изменяться; хорошая идея для таких файлов — включить локальные списки переменных для установки backup-by-copying-when-mismatch  (см. Раздел 31.2.5 [Переменные файла], с. 351).

Выбор переименования или копирования управляется тремя переменными. По умолчанию делается переименование. Если переменная backup-by-coping — не nil, то используется копирование.  В противном случае, если переменная backup-by-copying-when-linked не равна nil,  то делается копирование для файлов, которые имеют несколько имен, но может все же  делаться переименование,  когда редактируемый файл имеет только одно имя. Если переменная backup-by-copying-when-mismatch  — не nil, тогда, если переименование привело бы к изменению владельца файла или группы, то делается копирование. backup-by-copying-when-mismatch  по умолчанию равна t, если вы запустили Emacs как привилегированный пользователь.

Когда  файл находится под управлением системы контроля версий (см.   Раздел 14.7 [Управление версиями], с. 116), Emacs обычно не создает резервных копий как обычно. Но извлечение и фиксирование отчасти подобны созданию резервных копий.  Они похожи, к сожалению, и тем, что как правило разрушают жесткие ссылки, разъединяя имя файла, к которому вы обратились, и все другие имена этого же файла. Это не вина Emacs — это делает система управления версиями.

14.3.2  Защита от одновременного редактирования

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

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

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

Если вы начнете изменять буфер, когда файл, к которому он обращается, захвачен кемто еще, это приведет к столкновению, и Emacs спросит вас, что делать, вызвав лисповскую функцию ask-user-about-lock. Вы можете переопределить эту функцию для своих нужд. Стандартное определение этой функции задает вам вопрос и принимает три возможных ответа:

s                 Перехватить захват.  Тот  пользователь, кто  уже  редактировал  файл, теряет захват, а вы его приобретаете.

p                Продолжать.  Идти  дальше  и редактировать файл, несмотря на  то,  что  он кем-то захвачен.

q                Выйти. Это приводит к ошибке (file-locked), а изменения, которые вы пыта-

лись сделать в буфере, в действительности  не будут иметь места.

Заметим, что захват работает на основе имени файла; если файл имел несколько  имен, Emacs не  осознает, что  два имени — это один и тот  же  файл, и не  может предупредить двух пользователей о попытке редактирования одного и того же файла под разными именами. Однако, основание захвата на именах означает, что Emacs может блокировать редактирование новых файлов, которые фактически  не существуют, пока их не запишут.

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

Если в Emacs или в операционной системе случается фатальный сбой, это может оставить файлы захвата, которые уже  потеряли актуальность.  Поэтому вы можете  иногда получить предупреждение о мнимых столкновениях. Когда вы обнаружите, что столконение ложно, просто используйте p, чтобы велеть Emacs продолжать.

Источник: Ричард Столмен, Руководство по GNU Emacs

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий