← Все статьи · 2026-06-12

5 типов conflict copy в Obsidian — откуда берутся и как их починить

Conflict copy — это файл вида Note (Karim's iPhone).md или Note (conflicted copy 2026-06-12).md, который появляется в vault рядом с оригиналом. Внутри — версия заметки, которую синхронизатор не сумел слить с тем, что лежит в основном файле. Содержимое теряться не должно (обе версии сохранены), но вручную сравнивать и сливать приходится самому.

Ниже — пять реальных сценариев, которые приводят к conflict copy в Obsidian, в порядке частоты по жалобам пользователей. По каждому — что именно ломается и как починить.

Краткий ответ

Conflict copy появляется, когда два устройства независимо изменили один и тот же файл, и синхронизатор не может определить, чья версия правильнее. Универсального решения нет: iCloud Drive, Dropbox, Google Drive и Obsidian Sync создают конфликт-копию; Syncthing создаёт .sync-conflict файлы; Remotely Save затирает одно из изменений. Полностью избежать conflict copy для текста позволяют только CRDT-синхронизаторы (Rhyolite Sync) — они автоматически сливают одновременные правки в один файл.

1. Правка на двух устройствах между сессиями синхронизации

Что происходит. Открыли заметку на ноутбуке утром, потом дописали что-то на телефоне в метро (без интернета), потом вернулись к ноутбуку. iCloud / Dropbox / Obsidian Sync видят: ноутбук модифицировал файл в 09:00, телефон — в 11:30, оба не знают о правках друг друга. Создаётся конфликт-копия.

Как починить.

  • Открыть оригинал и conflict copy рядом в Obsidian.
  • Через плагин Diff View или внешний diff (Meld, Beyond Compare) сравнить две версии.
  • Скопировать недостающие куски из конфликт-копии в основной файл.
  • Удалить файл (conflicted copy).

Как не повторять. Использовать синхронизатор с CRDT-алгоритмом для текста — он сольёт обе версии автоматически без создания копий.

2. SQLite-файлы плагинов на iCloud Drive

Что происходит. Плагины типа Dataview, Tasks, Excalidraw, Spaced Repetition хранят индексы в SQLite-файлах внутри .obsidian/plugins/<name>/. iCloud Drive не обновляет SQLite атомарно — синхронизирует только частично записанные страницы. В результате файл с базой повреждается, плагин падает, иногда тянет за собой conflict copy на сами заметки.

Как починить.

  • Закрыть Obsidian на всех устройствах.
  • Удалить повреждённую базу плагина (часто <plugin>.db или cache.json).
  • Перезапустить Obsidian — плагин пересоберёт индекс.

Как не повторять. Добавить .obsidian/plugins/<plugin-name>/cache* в исключения iCloud (или в .icloud ignored через xattr). Альтернатива — синхронизировать сам vault без .obsidian/ папки.

3. Одновременная правка через мобильную и десктоп-версию

Что происходит. Одно устройство открыло Obsidian как редактор. Второе — открыло тот же файл через системный editor (Files на iOS, Finder Quick Look на macOS) и сохранило. Obsidian не знает о внешнем изменении до следующего сканирования vault. На следующей синхронизации получает два timestamp'а — создаётся conflict copy.

Как починить. Стандартный merge как в #1.

Как не повторять. Никогда не редактировать vault-файлы вне Obsidian, если он одновременно открыт. Использовать только один редактор за раз.

4. Файлы переименованы синхронизатором при загрузке

Что происходит. Dropbox/Google Drive иногда добавляют (1) или (Karim's MacBook) к именам файлов при разрешении конфликтов. Obsidian видит новый файл с другим именем — но это не conflict copy в техническом смысле, это два отдельных файла с одинаковым содержимым (или почти одинаковым). Бэклинки [[Note]] ведут только на оригинал. Файл с суффиксом висит в vault как дубликат.

Как починить.

  • Найти все файлы с подозрительными суффиксами через поиск Obsidian: path:"(1)" OR path:"conflicted".
  • Просмотреть, есть ли уникальный контент в дубликате.
  • Удалить дубликат или слить с оригиналом.

Как не повторять. Это структурная проблема Dropbox/Google Drive — она не лечится их настройками. Перейти на синхронизатор, который не модифицирует имена файлов.

5. Большие attachments — картинки, PDF, видео

Что происходит. Текстовые файлы Obsidian можно сливать через CRDT. Бинарные — нельзя: нет операции «слить два разных PNG в один». При одновременной правке (например, разные device'ы аннотировали один PDF) синхронизатор обязан выбрать одну версию и создать копию второй. Это корректное поведение, не баг — данные не теряются, но обработать вручную всё равно нужно.

Как починить.

  • Сравнить две версии (для картинок — открыть рядом, для PDF — пройти аннотации).
  • Решить, какая версия корректная.
  • Удалить лишнюю.

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

Сводно: что использовать, чтобы не возвращаться к этому

  • Если важно полное отсутствие conflict copy для текста — синхронизатор с CRDT-резолвером (например, Rhyolite Sync — описание на главной).
  • Если устраивает ручной merge раз в неделю — Obsidian Sync, iCloud Drive (только Apple-устройства).
  • Если бесплатно важнее автоматики — Syncthing с дисциплиной never-edit-on-two-devices, или Obsidian Git для текстового vault'а.

Полное сравнение всех вариантов с критериями — на странице сравнения.