Так можно параноиком стать. Срочно проверяй все остальные файлы!

UPD Ого, 5 человек подписаны, похоже это эпидемия.

Где-то в интернетах проскакивала мысль что такое могло произойти из-за физических свойств жёсткого диска, когда в одно место всё время пишутся единички, а потом внезапно нолики — при чтении всё равно могут получиться единички из-за того что жестяк не может размагнитить эту область. Возможно ли такое и какие ещё причины могут вызывать такое отличие?

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

Гораздо вероятнее такая хрень из-за оперативной памяти. ECC - рулит.

в процессе выравнивания раздела прилетела частица из космоса и поменяла бит в RAM %)

Там используются какие-то простенькие проверочные суммы

Там используется ECC по алгоритму Рида-Соломона, который надёжнее кодов Хэмминга, используемых в ECC RAM :) Обусловлено это гораздо меньшей надёжностью носителя и, соответственно, гораздо большим шансом нарваться на ошибку.

какие ещё причины могут вызывать такое отличие?

1. Стеганография: это условный сигнал «штирлицу».
2. Однобитовая часть трояна/вируса, остальные биты загрузятся позже :)

Там используется ECC по алгоритму Рида-Соломона, который надёжнее кодов Хэмминга, используемых в ECC RAM :) Обусловлено это гораздо меньшей надёжностью носителя и, соответственно, гораздо большим шансом нарваться на ошибку.

Буду знать, спасибо за поправку.

А точно проблема не софтовая? Может быть, умный просмотрщик jpeg-ов поставил какой-нибудь флаг в файл?

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

Много ты таких умных просмотрщиков знаешь?

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

При передаче по сети, например, зачастую вообще отсутствует контроль ошибок

Контрольные суммы, не? На уровне Ethernet, IP, TCP как минимум. 100% надёжности они конечно не дают, но вероятность их все проскочить очень маленькая

Может быть виновато что угодно.

Была как-то проблема с raid-контроллером, который иногда, после передачи определённой последовательности данных (минимальный размер последовательности который удалось идентифицировать был где-то в 1 МБ) портил один бит. Засекли на передаче многогигабайтных архивов.

Может быть, умный просмотрщик jpeg-ов поставил какой-нибудь флаг в файл?

Сильно вряд-ли, эти картинки с момента последней архивации не просматривались и изменённый бит находится где-то в середине файла, а не в начале.

А в каком по счёту байте находится этот бит и в какой позиции? Можешь сам файлик показать?

тебя ж за/раз-банили. или ты опять?

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

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

Можешь сам файлик показать?

Вечером смогу.

windows image viewer.

в старых версиях при повороте картинки сразу сохранял результат в файл.

под онтопик таких не знаю, потому что если встречаю - сразу выкидываю

минимальный размер последовательности который удалось идентифицировать был где-то в 1 МБ

Да, эти файлы весят несколько мегабайт, но рейд-контроллера нет.

Зато есть дисковый контроллер, ethernet контроллер и куча других контроллеров, да и просто диск, каждый из которых может сбоить как на постоянной основе, так и на временной.

При битой памяти такое может быть.

Контрольные суммы, не?

Да, но есть слабые места. Например, при NAT пересчитывается контрольная сумма TCP. При том что NAT обычно делается девайсами, не отличающимися особой надежностью. Ethernet FCS вообще действует в кабеле от сетевушки до сетевушки. В любом бридже пакет может храниться в памяти без контрольной суммы.

Реально выручает заворачивание сессии в SSL или SSH.

Один известный юзерскрипт даёт возможность постить картинки как раз с изменённым битом - для обхода проверки на дубликат вроде как. А картинка всё равно отобразится, jpg же.

А картинка всё равно отобразится, jpg же.

только после этого бита отображаться будет мусор

только после этого бита отображаться будет мусор

В моём случае обе картинки отображаются полностью и визуальных отличий не видно.

нет, не так: два идентичных бита, отличаются файлами...

В конце не видно.

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

Как и обещал:

Правильный файл: https://cdn.anonfiles.com/1410879785382.jpg
Неправильный файл: https://cdn.anonfiles.com/1410879694795.jpg
Позиция в байтах: 0x275431

И ещё одна пара из того же каталога:
Правильный файл: https://cdn.anonfiles.com/1410879941314.jpg
Неправильный файл: https://cdn.anonfiles.com/1410879888590.jpg
Позиция в байтах: 0x1F8431

опять касперский эникейщиков набирает?

Странно, что никто не сказал «виндопроблемы».

в процессе выравнивания раздела прилетела частица из космоса и поменяла бит в RAM %)
частица из космоса

Угадал 8)

опять касперский эникейщиков набирает?

Где?

Товарищ намекает что это мол тестовое задание Касперыча. И, кстати, уверен что байт ровно один?

Товарищ намекает что это мол тестовое задание Касперыча

Я не в курсе чего там у свинсперского, у меня реальная ситуация.

И, кстати, уверен что байт ровно один?

Да. И не байт, а именно бит, ссылки на файлы запостил выше.

Санкции, импорт нулевых битов в РФ резко сократили.

какие ещё причины

1. Хреновый шлейф к венику подцеплен. Или контакты. Или разъёмы. Или контроллер.
2. Глючит ОЗУ. ЕЦЦ нема. Или очень магнитно. Или перегрев. Или разгон.
3. Глючит камень. Адовые электромагниты. Или просто глючный.
4. Глючит ОС или софт, занимающийся копированием. Всякое бывает.
5. Ключит промежуточный носитель. Сетевуха, флешка, дискета, болванка и любое другое может запросто сбойнуть.

атрибут файла, поди?

атрибут файла, поди?

Атрибуты файлов пишутся в служебные области ФС, а не посреди самих файлов. Или ты о чём-то другом?

даже если они в архиве?

т.е. ты всегда побайтово сравниваешь файлы и тут внезапно обнаружил что matrix has you?

ЫЫ... видишь баба в красном пошла?

даже если они в архиве?

Расскажи каким образом наличие атрибутов файла в архиве влияет на его целостность, ага. Пути к файлам внутри архива тоже внутри картинок пишутся?

P.S. Если что — „неправильный” файл не архивировался.

т.е. ты всегда побайтово сравниваешь файлы

В этом каталоге — да.

и тут внезапно обнаружил что matrix has you?

Угу. Сейчас вот иду за белым кроликом пишу рыжей белке.

Раскопал у себя на том же разделе ещё пару фильмов (mkv), у которых контрольные суммы известны и раньше совпадали, но теперь не совпадают с моими, разбил их на куски по 50 мегабайт (52428800 байт) и сравнил их, в результате у одного фильма с изначальным размером 5.22 гигабайт (5612823907 байт) три фрагмента:

фрагмент 3, позиция 0x16BC42B, байт 0xBC → 0xAC;
фрагмент 74, позиция 0x0D9642B, байт 0x14 → 0x04;
фрагмент 80, позиция 0x219642B, байт 0x31 → 0x21;

и у другого с изначальным размером 7.77 гигабайт (8352445490 байт) восемь фрагментов:

фрагмент 22, позиция 0x08BC42B, байт 0x75 → 0x65;
фрагмент 48, позиция 0x134E42B, байт 0x34 → 0x24;
фрагмент 77, позиция 0x30EE42B, байт 0xFC → 0xEC;
фрагмент 81, позиция 0x08EE42B, байт 0xF8 → 0xE8;
фрагмент 118, позиция 0x072B42B, байт 0x35 → 0x25;
фрагмент 127, позиция 0x251B42B, байт 0xF8 → 0xE8;
фрагмент 140, позиция 0x1B1B42B, байт 0xD0 → 0xC0;
фрагмент 152, позиция 0x1AFB42B, байт 0x1F → 0x0F;

различаются одним байтом.

Упс

Не посмотрел что это hex.

Как и обещал:

Правильный файл: https://cdn.anonfiles.com/1410879785382.jpg
Неправильный файл: https://cdn.anonfiles.com/1410879694795.jpg
Позиция в байтах: 0x27542B

И ещё одна пара из того же каталога:
Правильный файл: https://cdn.anonfiles.com/1410879941314.jpg
Неправильный файл: https://cdn.anonfiles.com/1410879888590.jpg
Позиция в байтах: 0x1F842B

Пофиксил.

Т.е. согласно этой статистике видно что все позиции заканчиваются на 0x42B и первая половина байта в этих позициях имеет склонность уменьшаться на единицу (т.е. в битах вместо, например, 11111111 на выходе имеем 11101111).

cast Harald

2014
кто ещё сохраняет картинки в jpeg и жалуется на искажение в 1 бит

картинки в jpeg

Смотри выше про mkv и описанную мной закономерность. Проблема не в формате, проблема на более низком уровне.

интересно как :)

возможно в кэше процессора где-нибудь бит повредился и всегда 0 выдаёт