Как отличить реальный лишний файл Immich от возможного расхождения Unicode-нормализации: read-only сравнение пути, канонической эквивалентности и checksum без массового удаления.
Сначала определите класс Integrity-ошибки
Официальная страница Immich разделяет untracked files, missing files и checksum mismatches. Untracked означает, что путь найден в каталогах Immich, но не связан с записью базы; missing — обратное; mismatch говорит о различии сохранённой и фактической контрольной суммы. Эти категории нельзя лечить одной кнопкой. Выберите одну запись с нелатинским или акцентированным именем и сохраните тип отчёта, каталог и наличие соответствующего asset в интерфейсе. Не удаляйте файл и не запускайте очистку миниатюр до проверки. Документация советует разбирать сторонние untracked по одному, потому что безопасное удаление регенерируемых производных файлов не переносится автоматически на оригиналы.
Сравните видимое имя и последовательность кодовых точек
Два имени могут выглядеть одинаково, но иметь разное двоичное представление. UAX #15 определяет NFC как каноническую декомпозицию с последующей композицией, а NFD — как каноническую декомпозицию; канонически эквивалентные строки получают одну форму после одинаковой нормализации. На read-only копии выведите кодовые точки имени из отчёта и фактического каталога, затем сравните исходные строки и их NFC и NFD. Не переименовывайте оригинал ради теста: это изменит состояние файловой системы и может породить новую запись. Если исходные байты различаются, но обе пары совпадают после NFC и NFD, зафиксирован конфликт представления, а не автоматически доказанный баг Immich.
Добавьте checksum и связь с asset
Нормализация имени отвечает только за строку пути. Отдельно проверьте, существует ли asset с ожидаемыми метаданными и совпадает ли контрольная сумма оригинала с той, которую хранит система. Не публикуйте сам файл, EXIF, геолокацию или полный путь. Если checksum различается, гипотеза только о NFC/NFD недостаточна; следуйте ветке mismatch и исследуйте хранилище. Если checksum совпадает, asset виден, а отличие остаётся только в канонически эквивалентном имени, это сильный пакет для разработчиков, но не разрешение удалять помеченный объект. ASCII-контрольный файл полезен как сравнительная строка, поскольку UAX отмечает, что ASCII не меняется при нормализации, однако один успешный контроль не определяет масштаб.
Критерии остановки перед очисткой
Остановитесь, если запись относится к original upload или library, если непонятно, есть ли резервная копия, либо если отчёт содержит тысячи элементов. Не применяйте нормализацию имён массовым rename-скриптом: она меняет пути, на которые может ссылаться база и контейнерный mount. Для issue достаточно версии Immich, ОС хоста, типа файловой системы, категории Integrity, двух обезличенных последовательностей кодовых точек, результатов NFC/NFD и checksum. Не прикладывайте compose, `.env`, токены, частные volume paths и фотографии. Свежий issue заявляет конкретную реализационную причину, но пока остаётся открытым без комментариев; в материале она используется как проверяемая граница, а не как подтверждённый диагноз.
Материал подготовлен редакцией VOne с применением ИИ для дерева решений; категории сверены по Immich Docs, Unicode — по UAX #15, а issue отделён от доказательств.
Источники и проверка
- Immich Docs — System Integrity проверено 2026-08-10
- Unicode Standard Annex #15 — Normalization Forms проверено 2026-08-10
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.