Введение
Представьте общий диск на компьютере A, расшаренный для компьютера B по простому SSH. На диске лежит один файл; оба компьютера уходят в офлайн, затем вы вносите разные изменения в локальные копии и снова подключаете машины.
Что произойдёт с файлом при повторном соединении? Ответ зависит от того, как организована версияция и блокировка файлов — без специальных мер возможно перезаписывание, конфликты или потеря данных.
Сценарий: одновременные изменения на общем диске
Если общий диск реализован как простое сетевое хранилище без системы контроля версий, поведение обычно диктуется файловой системой или механизмом синхронизации. Часто последняя операция записи перезаписывает предыдущую версию файла — фактически «last write wins». Это означает, что изменения одного компьютера могут полностью заменить изменения другого.
При некоторых способах синхронизации могут возникнуть дополнительные последствия: создание дубликатов, меток конфликтов или уведомлений. Но без специального VC (version control) автоматического «умного» слияния изменений не происходит.
Почему это проблема контроля версий
Это классический вопрос версионирования файлов и общих баз данных. Чтобы решать такие ситуации, были разработаны и развивались системы контроля версий (VC). Они дают понятные правила разрешения конфликтов и сохраняют историю изменений.
Два подхода к версионированию
Оптимистичная версияция (multiversion concurrency control)
В оптимистичных системах документ могут редактировать сразу несколько пользователей. Если правки касаются разных, легко различимых и несконфликтующих областей, обе версии принимаются и автоматически сливаются.
Пример: UserA добавил абзац в главе 1, а UserB — в главе 2; обе правки объединяются без вмешательства. Но если правки затрагивают одинаковые данные, возникает конфликт и его должен разрешить хотя бы один пользователь — обычно тот, кто последний закончил работу.
Пример конфликта: UserA редактирует §1.0.0 в своей копии, а одновременно UserB удаляет §1.0.0 в своей копии — ситуация требует ручного вмешательства.
Пессимистичная версияция (locking)
В пессимистичном подходе пользователь «выходит» документ или ставит блокировку на строку в таблице — до снятия блокировки другие не имеют права записывать эти данные. Такой подход гарантирует атомарность транзакций и предотвращает одновременные конфликтующие правки.
Сценарий: UserA блокирует документ, вносит изменения, затем «коммитит» или отменяет правки и снимает блокировку — после этого другие пользователи получают возможность редактировать. В базах данных это часто реализуется через транзакции и механизмы блокировок.
Примеры из реальных приложений
Microsoft Word и LibreOffice Writer используют пессимистичную модель: при открытии документа для редактирования создаётся .lock файл в той же папке, что и документ. Пока .lock существует, другие пользователи могут просматривать файл, но не сохранять изменения в том же месте.
В таких случаях можно открыть документ и сделать «Save as…», создав копию с изменениями, но оригинал останется заблокированным до удаления .lock. Аналогично, в системах с чек-аут/чек-ин пользователь должен «check in» документ, чтобы снять блокировку.
Плюсы и минусы обоих подходов
Оптимистичная версияция даёт одновременный доступ многим пользователям и гибкость в работе. Однако при появлении конфликтов требуется их разрешение, и это может привести к хаосу при отсутствии дисциплины или инструментов для слияния.
Пессимистичная блокировка обеспечивает целостность и атомарность изменений, но рискованна в ситуациях, когда блокировка остаётся «зависшей» — например, пользователь уехал в отпуск, оставив документ в чек-аутах. Тогда требуется вмешательство администратора для разблокировки.
Короткие рекомендации применительно к вашему сценарию
Если на общем диске нет системы контроля версий или блокировок, при повторном подключении, скорее всего, одна из версий перезапишет другую. При использовании оптимистичной VC возможна автоматическая слияние при несовпадающих изменениях или уведомление о конфликте при пересечении правок.
Если используется пессимистичная блокировка (как в Word/Writer), в идеале второй пользователь не сможет сохранить изменения в том же месте, пока не будет снята блокировка.
