контрольная сумма md5sum эскизов (thumbnails)

контрольные суммы

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

будь добр, покажи, а то я смотрел и не нашел(

https://github.com/KDE/ffmpegthumbs

Может это?

Ну так может они в эту строку file:///media/home/file.mkv досыпают свою соль.

мне бы переформатировать команду в bash и желательно одной строкой, я видел это, но немного не то что мне надо

как вариант, считают они одинаково, а вот эскизы создают разные, с разными метаденными

это как?

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

а смысл в соли? это ж не пароль

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

"file:///home/user/Pictures/1.png"      : 9E1CB41E7B11E5FA2505BDB494A43B94.png
"㐆㐈_file:///home/user/Pictures/1.png" : A28AB93355AB389D90DFE9DF0F652AD1.png

а, ну возможно, да

Похоже они туда еще inode добавляют:

https://github.com/linuxdeepin/dde-file-manager/blob/master/tests/dde-file-manager-lib/interfaces/ut_dthumbnailprovider.cpp#L78

похоже, как это получить посредством баш или какого-либо скрипта, желательно без си?

Как-нибудь так, вопрос только куда и как они инод добавляют в строку:

 $ stat -c "%ifile://%n" ~/.bashrc | md5sum
0638501ce4a69e60bc085b1eedc8b174  -

Но зачем?

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

Если именно что перезаписать файл, поднимется mtime, а inode останется прежним. Инвалидировать надо по содержимому, а inode совершенно не при делах.

а inode останется прежним

Только что проверил на BTRFS - это не так.

$ echo c > x # перезаписать

Поправил :)

$ mv c x # перезаписать

Инвалидировать надо по содержимому

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

Поправил :)

Фигню поправил, расправь обратно.

inode сменился? Значит это другой файл, миссия по перезаписи оригинального файла провалена.

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

От чего? От нехеширования невтемачного inode может стать только быстрее.

man mv

mv - move (rename) files

$ echo a > x
...
$ echo c > x  # перезаписать

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

echo c > x # перезаписать

У тебя тот же файл, но с другим содержимым.

Да. Такая вот замена содержимого с сохранением идентичности называется «перезаписать файл».

Наверное правильно будет время модификации добавлять в хэш.

Правильнее сравнивать время модификации, чтобы узнать, что пора инвалидировать кэш, но это вопрос ортогональный вопросу «что там забыл inode».

Более вероятно. Начать с того, что тумбнаилы создаются нескольких размеров, маленькие, средние, большие. Во-первых, сравнить размеры, в смысле разрешения картинок. Во-вторых, в данном случае понятие «идентичное изображение» очень размыто. Чуть измени дефолтный уровень сжатия. На глаз будут идентичны, но абсолютно разные по коду, по хешу.

можно еще повернуть на пол градуса, на глаз не заметно, так стеганографические данные, вшитые в картинку можно изничтожать, повернул картинку на пол градуса и все спрятанное похерилось

немного не понял, как это применительно на конкретном пути, например file:///media/home/file.mkv?
stat -c "file:///media/home/file.mkv" ~/.bashrc | md5sum
02fdd95f34c50cc94c15d81d6bfd1c5f -
не дает ожидаемый кеш.
682433b1f02832783d4cb739d2e705ff.png, 33a417e81b4f8894d1a23406e827a23b.png 44feee170f71b4894f399af9f5a8eb33.png

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

немного не понял, как это применительно на конкретном пути, например file:///media/home/file.mkv?

stat -c "%ifile://%n" /media/home/file.mkv | md5sum

# %i  inode
# %n  file

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

0123456-file:///media/home/file.mkv
0123456_file:///media/home/file.mkv
file:///media/home/file.mkv-0123456
/media/home/file.mkv(0123456)
и т.д.

мне почему-то кажется, что принцип должен быть проще

хорошо, а можно ли поймать inode во время создания эскиза в том же dde-fm какими-либо средствами типа journalctl -f или чем-то еще?

Можно просто его посмотреть:

stat -c "%i" исходный_файл_для_эскиза.mkv

Но хэш может браться не из названия, а из содержания файла:

md5sum file.mkv

Попробуйте сравнить с этим.

итак, inode для файла file:///media/home/file.mkv равен 11, как я могу это использовать?

Попробуйте сравнить с этим.

уже пробовал, не то(

как я могу это использовать?

Подставлять в строку «file:///media/home/file.mkv» и смотреть результаты md5sum.

в какую именно строку?

в какую именно строку?

Из которой берется md5, вы говорите, что это «file://путь к файлу», так ли это, я не знаю. Используется ли при этом inode файла, тоже под вопросом, тем более, что как я понимаю, этот mkv находится в другой файловой системе. И его inode (11) не характерен для локальных файлов. У меня иноды такого порядка в /tmp c tmpfs.

Час два играл в эту игру.

Вот так:

echo -n $(stat -c "file://%n%i" /media/home/file.mkv) | md5sum

В коде-то явно видно, что имя файла + инод.

Но долго доходило, что QCryptographicHash::hash(some_qstring.toLocal8Bit(), QCryptographicHash::Md5).toHex(); это не одно и то же, что и echo some_qstring | md5sum и что надо откусывать перевод строки перед передачей в md5sum.

Круто, проверил, работает и с другими путями, спасибо!

Думал, что замена эскиза в $HOME/.cache/thumbnails/large решает ситуацию, но увы, после генерации нужного эскиза при открытии в dde-FM нужного каталога эскиз пересоздаётся заново средствами dde-FM, вопрос как изменить поведение этого файл-менеджера?
или стоит создать новый тред?

Думал, что замена эскиза в $HOME/.cache/thumbnails/large решает ситуацию

Виноват, не понял - какую именно «ситуацию»? Перечитал стартовое сообщение, ничего не увидел про «ситуацию».

Вы хотите их подменять своими что ли? С какой целью?

Имя файла это только полдела. Там внутри у того PNG еще должны быть правильные tEXtThumb::MTime и tEXtThumb::URL. По крайней мере MTime - точно, ибо:

const QImage image = ir.read();

    if (!image.isNull() && image.text(QT_STRINGIFY(Thumb::MTime)).toInt() != (int)info.lastModified().toTime_t()) {
        QFile::remove(thumbnail);

        emit thumbnailChanged(absoluteFilePath, QString());

        return QPixmap();
    }

Виноват, не понял - какую именно «ситуацию»? Перечитал стартовое сообщение, ничего не увидел про «ситуацию».

ситуация начиналась отсюда, но активности в треде не было и я пытаюсь «ситуацию» разобрать по частям

Понятно.

Вообще-то забавная игра.

На моём тестовом файле:

• thunar записывает MTime = 1623434142.000000
• convert -thumbnail 256x256 (как в том bash-скрипте) записывает MTime = 1623434142
• а dde на том же тестовом файле пишет в метаданные MTime = 1623434143

:D

Может потом ещё в неё поиграю ) Смотрите у себя, сравнивайте, ищите откуда dde лишнюю секунду берёт ) У меня пока нет вариантов )

я проверил, если скопировать эскиз из $HOME/.cache/thumbnails/normal в $HOME/.cache/thumbnails/large и переименовать, то dde-FM ее принимает, только не могу понять куда в скрипт засунуть команду копирования, поковыряюсь на досуге, спасибо за подсказки.
ЗЫ подскажите, как посмотреть этот самый MTime?

подскажите, как посмотреть этот самый MTime?

я так смотрел:

$ exiftool 111.png | grep "Thumb M Time"
Thumb M Time                    : 1623434142

$ exiftool 41e5228d770bf4eba91dc04c76f09b81.png | grep "Thumb M Time"
Thumb M Time                    : 1623434143

$ exiftool 4c95345e915ab78b3da5a05be9562f5a.png | grep "Thumb M Time"
Thumb M Time                    : 1623434142.000000

file.mkv | md5sum

На весь 100GB файл, ну конечно же нет.

ищите откуда dde лишнюю секунду берёт

Ох, жеж.. Похоже это не deepin (Рафик ни в чем не уиноват).. Это сам imdb-thumbnailer зачем-то секунды дёргает в дате модификации файла туда сюда.

case $second in
					[13579] )	second=$((second-1)) ;;
					* )		second=$((second+1)) ;;
				esac

				incomplete_time=${file_time:0:18}

				new_cover_name=$incomplete_time$second-$file_size

				if [[ -f $cover_path/$cover_name.png ]]; then
					mv "$cover_path/$cover_name.png" "$cover_path/$new_cover_name.png"
				fi

				touch "$file_path" -d "$incomplete_time$second"

Какой-то очень странный скрипт, который САМ может менять дату-время создания МОИХ файлов с какого-то рожна.

А потом ещё всем интернетам рассказывает какие у меня видео. А у меня тут всего-то пара роликов и их точно не может быть на imdb )

Ну его к лешему )

А потом ещё всем интернетам рассказывает какие у меня видео.

это в какой строке он рассказывает интернетам?

САМ может менять дату-время создания МОИХ файлов с какого-то рожна

он же вроде время эскизов выставляет(я если честно этот отрывок кода сам не понимаю, но оно почему-то работает), а не время создания файла видео

Ну его к лешему )

Ну, чтож, буду ковыряться дальше, и на том спасибо, сдвиг и так уже есть)