Транзакционная модель для редактирования больших двоичных файлов

Question

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

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

Есть ли какой-то простой процесс, с помощью которого я могу позволить пользователю как-то «зарегистрировать» скопированный файл как редактируемый файл, а когда они завершат все свои изменения, «завершить» файл?

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

Answer 1

Поскольку вы думаете о транзакциях и активности файловой системы, может быть полезно рассмотреть Transactional NTFS.Это не отвечает на ваш вопрос, но может дать вам новое понимание возможностей.Поскольку ваш вопрос помечен для C # и Windows, вы можете посмотреть на оболочку .NET, например здесь: http://offroadcoder.com/CategoryView,category,Transactions.aspx. Скотт Клюппель показывает, как сделать транзакционную NTFS, используя знакомую .NET идиому TransactionScope.Я быстро проверил, что сделал Скотт, и мне понравилось то, что я видел.

Answer 2

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

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

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

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

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

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

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

Answer 3

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

Также: если большой файл доступен для чтения, вам действительно нужно скопировать его перед редактированием?

Если изменения сравнительно небольшие по сравнениюпо размеру файла я бы записал действия пользователя как 'diffs' между исходным файлом и результатом.Если одно и то же место редактируется снова и снова, может быть полезно как-то «соединить» различия, чтобы не применять слишком много слоев различий.Пользователь, конечно же, видит файл со всеми динамически применяемыми разностями.

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

Answer 4

1. Создание и ведение записи (дБ?) Сеансов в централизованном месте.
2. Сессия состоит из имени пользователя, если оно у вас есть, или IP-адреса или того, что вы хотите использовать дляуникально идентифицирует пользователя и хэш байтов.Если хеш слишком обременителен для размера файла, вы можете попробовать полагаться на дату и размер файла.
3. Когда пользователь закрывает свой редактор, вы обновляете запись сеанса с помощью вышеуказанной информации и помечаете ее как неактивную.*
4. Когда пользователь снова откроет редактор, у вас должен быть доступ к вашей ключевой информации, то есть имени пользователя и информации о файле.Если вы найдете запись сеанса, это неактивный сеанс, который вы можете повторно активировать, в противном случае он либо был изменен, либо является совершенно новым.

Это соответствует вашим потребностям?