Цитата: Я предложил варианты, которые можно использовать, а ты уж сам подбирай, что тебя устроит...
Пока что юзаю вариант, не предложенный тобой (запись на сторонний сетевой NAS с рейдом). Через сеть в виде буфера + через парочку FIFO на обоих концах коннекта - пока что вроде ничего не падает... Подождем конечно, но с записью на локальный диск я бы
чего-нить подумал бы на твоем месте как разработчика. Поваленный FAT на диске - это далеко не битый тайл в кэше, это уже весьма сурьезно...
Цитата: у него же нет поля типа CRC..
На одном CRC мир не остановился.
Можно например банально попробовать распаковать ЖПЕГ в памяти со включенным вербосом от декодера, и посмотреть на выхлоп после операции. Если декодер скажет ОК - то картинку будем считать валидной, если выдаст сбойный чанк, который не смог распаковать - значит битая (особенно при принятии во внимание того, что стандартные жпеговые декодеры могут\будут останавливать дальнейшую распаковку если найдут еррор в теле текущего чанка и если взведено STOP_ON_ERROR - это выливается в "серое поле до конца картинки").
Либо взять из заголовка параметры жпегового битмапа, распаковать боди файла в памяти при взведенном STOP_ON_ERROR и сравнить размер распакованного битмапа с тем, что в заголовке. Серое поле - это нули, а нули можно отскипать в сторону. Если размер битмапа явно отличается от указанного в заголовке (особенно с откинутыми нулями) - то либо хидер битый либо битмап, что и требовалось доказать.
Либо взять превью из жпег-заголовка, опять же распаковать боди, уменьшить распакованное до размера взятой превьюхи и сравнить два битмапа (с некоторыми ненулевыми допусками, конечно).
Либо комбинировать все эти методы (они кстати применимы не только к жпегу, а к любому битмапу кроме RAW).
В любом случае, задача решаема (и давно есть утиль). Например оная на ура мне искала как-то битые тайлы в кэше САСа. Специально пару байт в теле файла редактором менял, и подсовывал утили - вылавливала на ура и вываливала списочек....
Порою дома в нычках седня, дам.
