Проверка каталога, вложенных каталогов и файлов на идентичность

Перетягиваю папочку в Thunar, а он по умолчанию и автоматически считается чексуммы при переносе.

Я тоже так сделал, но копирование с ненадёжных источников не даёт гарантий что повторное чтение даст те же хеши

Дык rsync.

Как им проверить результат копирования?

Скопировать в обратную сторону с –dry-run и чем-то там еще, не помню, и посмотреть на выхлоп.

в догонку

diff -r -q /folder1 /folder2

Как вариант:

IFS='
'
(cd mydir; sha256sum $(find . -type f |sort) |sha256sum)

rsync -u ...

Не так уж и сложно сделать по-нормальному:

(cd mydir;  find . -type f -print0 | sort -z | xargs -0 sha256sum | sha256sum)

Флешки это только для переноса инфы. Хранить на флешках нельзя.

ddrescue

сверяют каталог с подкаталогами на тему всё ли скопировалось и не попортились ли в процессе данные

Посчитать суммы для всех файлов в директории, рекурсивно:

md5deep -rl . > /tmp/sums

Показать файлы, для которых контрольные суммы не сошлись:

md5deep -x /tmp/sums -r .

по-нормальному

Нормальный вариант у меня. Без лишних опций и со встроенным $() вместо xargs. Мою команду запомнить проще.

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

Сами же будете мучаться и ругать какой баш кривой, не замечая того, что эти абсолютно неуместные переводы строк не стоят страданий и всё равно во многих системах запрещены (в POSIX, Windows, Plan 9) и многие чужие программы подразумевают это независимо от ОС.

твой код на моей флешке-переноске выдаёт:

bash: /usr/bin/sha256sum: Слишком длинный список аргументов

Надо просто выработать привычку делать нормально и не страдать.

Слишком длинный список аргументов

Докупи оперативной памяти, создай своп, увеличь ARG_MAX (благо на линуксе это законно). Сегодня машины имеют гигабайты памяти. Некоторые пользователи даже веб-браузеры запускают. Динамическая память — не нерешённая проблема, флешка — не петабайтный дата-центр.

Твой вариант работает потому, что xargs запускает команду несколько раз по ~1000 аргументов. Ты знал об этом? Когда в следующий раз будешь «нормально» создавать tar-архив с помощью xargs и увидишь, что часть файлов будет потеряна, вспомни клоуна под этим сообщением.

Надо просто выработать привычку делать нормально и не страдать.

Вот именно.

Тут опять будет специальная олимпиада, так что даю правильный ответ для тех, кого гугл забанил в яндексе:

rsync -cn /path/to/src/ /path/to/dst/

Обратить внимание на палки в конце путей, расшифровка буковок - в руководстве.

А вы с флешек тоже копируете с «!»?

Есть еще какой lsync, ни разу его не юзал.

Я сам лично все копирую через МС. Увы.

А я не знаю что там может быть на некоторых. Но чем таскать десяток флешек, лучше таскать одну. Я вот diff-ом обходиться привык. И думается мне что он не должен захлебываться от странных символов, но интересно посмотреть на другие варианты.

Btrfs + rsync.

sha256sum | sha256sum

Довольно элегантное решение 👍

batchprotect.sh

Когда в следующий раз будешь «нормально» создавать tar-архив с помощью xargs и увидишь, что часть файлов будет потеряна, вспомни клоуна под этим сообщением.

Не очень понял. Каким образом происходит потеря данных в xargs?

Если аргументов будет больше, чем ARG_MAX (~1000 на macOS, чуть больше в Linux), то xargs несколько раз запустит команду. Попробуй seq 100000 |xargs bash -c 'echo hello world'. Соответственно, обычный xargs tar cf junk.tar перезапишет архив.

А, понятно. Думаю, если уж кому-то приспичит добавлять файлы в архив таким образом (честно говоря, ни разу не было необходимости, всегда пакую ровно один каталог, в котором нет лишнего), то пусть используют --append.

Стоп. Предпосылка темы была в том что cp не умеет делать исключения. И как это связано с вашей задачей? Вы что тоже хотите копировать через cp и исключать какие то каталоги?

Если cp что то не сможет скопировать он напишет про это.

tar та ещё ловушка, если пытаться делать странное, а не паковать один каталог.

Там есть опция –files-from=FILE но она делает совсем не то, что все нормальные программы с подобной опцией. Правильный вызов тар для произвольно большой кучи файлов примерно такой (даже ключей порядок важен)

find ./dir/ -print0 | tar c --verbatim-files-from --null --files-from=- | xz > blah.tar.xz

Если cp что то не сможет скопировать он напишет про это.

Гораздо хуже. Если цп получит ошибку чтения файла - он оставит на диске недозаписанный файл. У rsync есть разные стратегии поведения в таких сценариях.

Если цп получит ошибку чтения файла - он оставит на диске недозаписанный файл.

Но он же сообщит про это?

А толку? В результате у тебя не консистентная копия. При повторной попытке скопировать файлы из того же места ты выберешь вариант "без перезаписи" и огрызок так и останется огрызком.

Ну и оно на каждом файле будет обрываться.

Как я понял, ему не нужно считывать не правильную информацию. Ему скорее важно знать что он считал не правильную информацию.

При первом копировании (с флешки) он будет знать что вот такой то у него файл не скопировался. Я хз как там ведет себя cp, вон МС предлагает это файл удалить.

Допустим cp не целиком скопировал 1 файл и не сообщил об этом. Тогда всякие контрольные суммы (сделанные сейчас) покажут что и там там файл нормальный, так как они его также подсчитают.

rmlint --backup -g --hidden -T ... [-D -j] -k -m ... или может rmlint --equal dir1 dir2

Стоит ли мне изобретать велосипед на баше

часто плохая идея

Флешки это только для переноса инфы. Хранить на флешках нельзя.

Я бы даже сказал, это те же самые дискеты. Если не хуже. Дискетки в основной своей массе хоть только бэдами поростали, т.е. несколько копий на одной дискете уже спасало, а флэшка дохнет в моменте и вся.

Допустим cp не целиком скопировал 1 файл и не сообщил об этом. Тогда всякие контрольные суммы (сделанные сейчас) покажут что и там там файл нормальный, так как они его также подсчитают.

Флэшку нужно отмонтировать и заново примонтировать перед подсчетом, ну или сбросить кэши, что скорее менее предпочтительно.

Ну тогда проще создать два торрент-файла. Один файл на источник, второй файл на назначение.

И потом просто сравнить 2 файла между собой.

Я не про это. Я про то что если в один момент с флешки читается пол-файла, ну или внутри файла образовались нули…

То почему при слеующем монтировании картина изменится?

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

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

вот прямо крик души, кэш и линукс это инь и янь жопогорения во всех проявлениях.

Можно подумать где-то другое.

Винда такого не позволяет, максимум покажет тупняк в прогресс-баре. Для непосвященного человека просто повод для лолкать, а вот линукс коварен донельзя.

Винда такого не позволяет, максимум покажет тупняк в прогресс-баре.

Ну да, канечно... копий о «безопасное извлечение устройств» сломлено море, и моя на пользаке недавно такое же узрела.