http://mikrotik.moscow Новое в теме Скопированные файлы имеют разные контрольные суммы. форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Fri, 31 Jul 2026 04:12:12 -0400 Скопированные файлы имеют разные контрольные суммы. RouterOS в форуме RouterOS.
Спасибо за такой подробный разбор этой проблемы! Я пытался обучить ИИ искать эти шаблоны в нескольких файлах, но пока безуспешно. Ну а пока, судя по сообщению автора темы, у нас похожая проблема на похожем оборудовании (у меня в сети ТОЛЬКО коммутаторы и роутеры MIKROTIK), и мне показалось интересным, что поиск моей проблемы в Google привел меня на форум MIKROTIK.
18.12.2024 18:11:00, debricker.]]> http://mikrotik.moscow/forum/forum57/87164-skopirovannye-fayly-imeyut-raznye-kontrolnye-summy./message414159 http://mikrotik.moscow/forum/forum57/87164-skopirovannye-fayly-imeyut-raznye-kontrolnye-summy./message414159 Wed, 18 Dec 2024 18:11:00 -0500 RouterOS Скопированные файлы имеют разные контрольные суммы. RouterOS в форуме RouterOS.
Да, но я хочу сказать, что не вижу «паттерна повреждения». На строке 03C540 пропущен байт 00 (в результате данные смещены на один байт) в позициях 8-11, четыре подряд идущих FF должны это подтвердить. На строке 03C560 отсутствует целый триплет, всё смещено вверх на 4 байта, пока на строке 03C5C0 внезапно не появляются 4 байта, и паттерн «17» снова синхронизируется. 00 и FF, или наоборот, могут означать XOR или инверсию бит, но 17 остаётся неизменным. Следующее отличие — кажется совсем другим паттерном, похоже, вставлены байты, и всё сдвинулось вниз на 16 байт.
18.12.2024 16:48:00, jaclaz.]]> http://mikrotik.moscow/forum/forum57/87164-skopirovannye-fayly-imeyut-raznye-kontrolnye-summy./message414158 http://mikrotik.moscow/forum/forum57/87164-skopirovannye-fayly-imeyut-raznye-kontrolnye-summy./message414158 Wed, 18 Dec 2024 16:48:00 -0500 RouterOS Скопированные файлы имеют разные контрольные суммы. RouterOS в форуме RouterOS.
Да, но, исходя из этих данных, не зная, как внутренние алгоритмы работают при передаче пакета, сложно выяснить причину повреждения данных.

P.S. Однажды, в начале 2000-х, когда я ещё учился, мне попалась статья о том, что был найден файл, который невозможно записать на CD-диск — определённая последовательность байтов (бит), которая после обработки "мозгами" привода выглядела как сигнатура начала сектора данных на CD и из-за этого привод зависал при записи такой последовательности. Если интересно, могу скинуть ссылку на русском, почитай — там, кажется, что-то похожее происходит при определённых условиях. (https://www.ixbt.com/optical/magia-chisel.shtml)
18.12.2024 14:44:00, debricker.]]> http://mikrotik.moscow/forum/forum57/87164-skopirovannye-fayly-imeyut-raznye-kontrolnye-summy./message414157 http://mikrotik.moscow/forum/forum57/87164-skopirovannye-fayly-imeyut-raznye-kontrolnye-summy./message414157 Wed, 18 Dec 2024 14:44:00 -0500 RouterOS Скопированные файлы имеют разные контрольные суммы. RouterOS в форуме RouterOS.
Обожаю невидимые скриншоты, они отлично сочетаются с темой доски… ИЗМЕНЕНИЕ: А, понятно, теперь видно. Исходный узор, похоже, состоит из повторяющихся 4 наборов по 12 триплетов, из которых 11 — 00FFFF, а один — 00FF17. При просмотре в шестнадцатеричном формате в 16 столбцов общий шаблон повторяется каждые 9 строк, 16×9=144 байта, 144/12/3=4. Повреждение файла странное (см. изображение).
18.12.2024 09:55:00, jaclaz.]]> http://mikrotik.moscow/forum/forum57/87164-skopirovannye-fayly-imeyut-raznye-kontrolnye-summy./message414156 http://mikrotik.moscow/forum/forum57/87164-skopirovannye-fayly-imeyut-raznye-kontrolnye-summy./message414156 Wed, 18 Dec 2024 09:55:00 -0500 RouterOS Скопированные файлы имеют разные контрольные суммы. RouterOS в форуме RouterOS.
Всем привет! Вижу, что тема старая, но меня также догнала похожая ситуация. Сразу прошу прощения за длинный рассказ, но он того стоит (кстати, история ещё не закончена). В течение года было три случая, когда пользователи жаловались на повреждение файлов, и в каждом из них нам не удавалось выявить закономерность, потому что у повреждённых файлов не изменялись временные метки (даже если файл лежал нетронутым, например, два года, он всё равно оказался повреждённым). Парадокс был в том, что даже несмотря на достаточно хорошую систему бэкапов (3 уровня, теневые копии, оперативные копии на сетевое хранилище, долгосрочные копии на внешние носители), оказалось, что повреждения были и в архивах (многочастные непрерывные архивы 7-ZIP, которые вообще исключают возможность повреждений внутри себя).

Например, в понедельник, 16 декабря 2024, пользователь сообщил, что файл, который он успешно открыл в пятницу, 13 декабря того же года, теперь повреждён, но все временные метки были ещё до даты инцидента (файл был создан в 2023, а изменён в ноябре 2024). Когда мы достали этот файл из архива от 6 декабря 2024, оказалось, что и там файл повреждён. Сначала думали на Microsoft DFS, затем на SAN и хранилище, но проблем там не нашли и обратили внимание, что подобные сбои были только с файлами определённого формата (Autodesk ArtCAM). Иногда, распаковывая архивы на другой машине и вне серверной с её сетью, выяснялось, что файлы из архива начинают открываться. Мы поместили их в нужные общие папки (восстановленные) и я стал сравнивать повреждённые файлы с извлечёнными из архива в HEX-редакторе и обнаружил отличия (на скриншоте в приложении — повреждённый файл слева, исправный справа).

Меня заинтересовало, что это похоже на простое инвертирование битов, но не всегда. Ещё страннее было то, что спустя время всё исправлялось само собой, и файлы чудесным образом начинали открываться и работать как надо (и из архивов, и из теневых копий, и из общей папки, то есть они точно не были просто скопированы из архива). Экспериментально выяснили, что помогает перезагрузка сетевого оборудования (главный 10-гигабитный роутер в серверной — CCR2004, а два подключенных к нему снизу — CRS354 и CRS328, которые связаны оптикой через WDM-волоконные передатчики). Также заметили, что в этот момент снижается отклик и скорость передачи между коммутаторами — проблема локализована как неполадка с оптическим соединением. Сейчас планируем заменить оптические передатчики, но корень проблемы ещё не найден. К сожалению, такая ситуация происходит достаточно редко, чтобы выявить объективную причину. Но точно можно сказать, что проблема именно в части передачи данных по сети и проявляется только с определёнными типами данных. Может, кто-то сможет распознать закономерность на скриншотах в приложении.

Несколько скриншотов для анализа:  
 
 
 

18.12.2024 09:48:00, debricker.]]> http://mikrotik.moscow/forum/forum57/87164-skopirovannye-fayly-imeyut-raznye-kontrolnye-summy./message414155 http://mikrotik.moscow/forum/forum57/87164-skopirovannye-fayly-imeyut-raznye-kontrolnye-summy./message414155 Wed, 18 Dec 2024 09:48:00 -0500 RouterOS Скопированные файлы имеют разные контрольные суммы. RouterOS в форуме RouterOS.
Программист в нашем офисе говорит, что иногда копирует большой файл по нашей сети, и при этом конечный файл получается того же размера, но с другой контрольной суммой, чем у исходного. Я пытаюсь понять, что может пойти не так. У нас два коммутатора Mikrotik (CRS328-24P-4S+ и CRS312-4C+8XG), соединённые оптической 10G ссылкой. Файл (примерно 20+ Гб) копировался с Windows Server (ссылка 5Gbit) на шаринг на другой Windows Server (тоже 5Gbit) с помощью Far Manager, после чего на обеих сторонах считались контрольные суммы CRC64. В случае несовпадения суммы файл копировался заново. За последние несколько месяцев он столкнулся с этой проблемой минимум дважды. MTU на обоих коммутаторах установлен на 1500. В статистике задействованных интерфейсов никаких необычных ошибок не видно. Я не смог воспроизвести проблему и склонен винить драйверы, Far, кэши Windows, жесткие диски и так далее, а не коммутаторы. Но всё же... возможно ли, что файлы каким-то образом искажаются в процессе копирования?
19.01.2022 10:35:00, zhenb.]]> http://mikrotik.moscow/forum/forum57/87164-skopirovannye-fayly-imeyut-raznye-kontrolnye-summy./message414154 http://mikrotik.moscow/forum/forum57/87164-skopirovannye-fayly-imeyut-raznye-kontrolnye-summy./message414154 Wed, 19 Jan 2022 10:35:00 -0500 RouterOS