Гарантирует ли Linux 100% сохранность файлов при копировании?

Нет такого механизма. И после скопированного файла действительно суммы сверять глупо, файл скорее всего будет в дисковом кеше в (ОЗУ) и не будет считан с флешки. Так что если проверять, то только после отключения/подключения...

насколько точной получилась копия

Ну где-то на 97.3%

В Linux существует какой-то внутренний механизм проверки целостности скопированного файла?

существует

Нет такого механизма.

Это ваши домыслы или факт? В чем проблема автоматически (фоном) сверить контрольные суммы после копирования файлов, и если они не совпали, сообщить? Вот ниже gnu_linux пишет, что есть такой механизм. Кому верить?

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

Это довольно бесполезная затея, которая ещё и будет тратить много ресурсов на I/O. Как уже сказали выше, сверять имеет смысл после отключени/подключения флешки, а не сразу. Сразу-то оно будет всё в порядке (иначе при копировании была бы ошибка), а вот не побьётся ли потом — вопрос. А ещё может побиться через неделю, через несколько подключений. В общем случае проблема не разрешима средствами самой ОС. Но ты вполне можешь сделать демон, который будет сверять по inotify сразу (но это довольно бесполезное), с определённой периодичностью, сразу после подключения флешки, или при любых условиях, которые тебя устраивают.

Как ты себе это представляешь? На каком-нибудь тормознутом HDD/флешке вычисление контрольных сумм и их сверка по времени будет сравнима с самим копированием.

Поэтому важные файлы проверяешь сам, на неважные забиваешь болт. Просто следи за ходом копирования и не размонтируй носитель раньше времени (Gnome, кстати, через GUI тебе это и не даст сделать).

Как ты себе это представляешь? На каком-нибудь тормознутом HDD/флешке вычисление контрольных сумм и их сверка по времени будет сравнима с самим копированием.

Про время как-то забыл, и правда долго иногда проверяет суммы. А других способов проверки целостности после копирования (более быстрых) не изобрели?

Поэтому важные файлы проверяешь сам, на неважные забиваешь болт. Просто следи за ходом копирования и не размонтируй носитель раньше времени (Gnome, кстати, через GUI тебе это и не даст сделать).

Да и в KDE вроде так нельзя, сначала докопироваться должно

и не размонтируй носитель раньше времени

Тут sync поможет.

А вы вот реально сталкивались с ситуацией, что файлик на флешку или диск скопировался без ошибки, но оказался битый?

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

Сквозного механизма нет, за каждый этап отвечает свой механизм. У винта\флешки свои механизмы контроля записи\чтения на блин\в микросхему, за целостность передачи по sata\NVMe отвечает механизм контроля чётности, за сохранность и обнаружение ошибок при работе с файловым кешем в ОЗУ отвечает механизм ECC. И вот тут слабое место, если используется память без ECC сбой ячейки обнаруживать\исправлять нечему.

Нет такого механизма.

https://github.com/FS-make-simple/rs-coder

А других способов проверки целостности после копирования (более быстрых) не изобрели?

Я не знаю таких.

Да и в KDE вроде так нельзя, сначала докопироваться должно

В KDE я не пробовал такую фигню делать. Есть - значит хорошо. Но там и без этого косяков хватает.

Например, время копирования часто рассчитывается немножко по-дебильному: сначала показывает субсветовую скорость копирования, 5G нервно курит в сторонке, потом процентах на 20% шкала останаливается и все начинает до-о-о-лго висеть на одном месте. Иногда даже отвисает.

Или более доставляющая проблема: скопировал файл на NTFS-флешку - все нормально, все открывается. Вставил в другой комп - пусто. Вставил обратно в свой - пусто. Да как так, мать твою через коромысло?

Да как так, мать твою через коромысло?

Это из серии «за что боролись, на то и напоролись». Отказ от прямой записи на флэш-накопители производители произвели мотивируя именно «повышением надёжности». Ну что, повысили?

rsync в помощь

Или более доставляющая проблема: скопировал файл на NTFS-флешку - все нормально, все открывается. Вставил в другой комп - пусто. Вставил обратно в свой - пусто. Да как так, мать твою через коромысло?

IMHO такое происходит только если юзер сам себе злобный деревянный Буратино. Если кеширование записи включено - флешку нужно размонтировать и дождаться окончания процесса записи содержимого кэша. И вот тут бывает что её выдёргивают не дождавшись разрешения от ОС, так как механически этому ничего не препятствует и визуальной сигнализации на флешке тоже часто нет. Можно конечно в синхронном режиме сменные накопители монтировать, причём ЕМНИП по дефолту они монтируются именно так, но я бы всё равно в случае с NTFS сначала отмонтировал, для надёжности, а потом дёргал, потому что ХЗ как там журнал закроется. Я лично NTFS уже давно на сменных накопителях не использую, меня устраивает exFAT, и монтирую в синхронном режиме. В итоге уже лет несколько ничего не терял.

потциент, узбагойтесь: если при чтении или заПиси произойдёт ожибга, вам об этодом явно нбичатают на эгране.

Разве rsync проводит чтение для подсчёта контрольных сумм, затем сбрасывает буфер, читает и записывает, затем сбрасывает буфер, читает и сверяет контрольные суммы? Нет.

Вот это требование:

независимо от того, какой способ копирования ты выбрал (графический или консольный)

означает, что способ должен быть не в программе, осуществляющей копирование, а где-то в системе (системной библиотеке или ядре). Но это не оффтопик, где есть CopyFileEx(), здесь есть read(), write() ну и sendfile(). Ядро не знает, что создаётся именно копия файла (которую нужно проверять)...

Кому верить?

Несомненно, верить gnu_linux, он же развёрнуто описал этот механизм.

Пример встраивания этого механизма в команду ″cp″ будет?

Я всегда размонтирую флешку, привычка еще с винды осталась. Так что либо KDE позволяет ее отмонтировать до окончания записи, либо каким-то образом неправильно определяет ход процесса. Потому что на других DE таких проблем я пока еще не замечал.

NTFS использую для больших файлов и потому что гарантированно на любом компе откроется. До exFAT пока руки не дошли. Надо будет заценить.

До exFAT пока руки не дошли. Надо будет заценить.

В exFAT нет журнала, так что не нужно. Более того в отличии от FAT там нет запасной файловой таблицы, что снижает вероятность восстановления данных.

sync

Ничего не читал кроме заголовка, но если нет гарантий со стороны железа, то их нет и на программном уровне. А их нет.

Мне нужна читаемость на любых осях. А нужен будет журнал - всегда можно поставить ext4.

И в чём тогда проблема продолжать использовать NTFS?

Юзер может не знать о такой особенности линуксов, я привык что в офтопике когда полоска доходит до конца и пропадает - флешку можно сразу размонтировать или вобще вытащить и всё будет ок, а например в lubuntu 18.04 после того как полоска дойдет до конца нужно еще подождать какое то время иначе файл будет поврежден или его вобще не будет, хорошо когда флешка с диодом и продолжает мигать после исчезания полоски, тогда понятно когда запись на самом деле завершена, а когда диода нет - пробую размонтировать и если ругается - ждем дальше - если размонтировалось, значит ок, можно что то покрасноглазить чтобы в интерфейсе учитывалась запись содержимого кэша ?

Винда монтирует сменные носители в синхронном режиме по умолчанию, если юзер это сам не отключил. В линукс в КДЕ тоже кажется так, могу наврать, проверять лень. В синхронном режиме кэш только на чтение работает. А в асинхронном режиме umount размонтирует ФС и выдаёт подтверждение только после того как кэши сброшены.

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

И в чём тогда проблема продолжать использовать NTFS?

Например в том что два из трёх smartTV в которые мне иногда приходится пихать флешку NTFS уже не понимают, только exFAT. А ещё журнал мне на ней не нужен, лишняя утяжеляющая сущность. Не храню на внешних носителях ничего критически важного, если ФС развалится ничего восстанавливать не буду, просто отформатирую заново и ещё раз запишу. Хотя уже несколько лет как ничего не разваливалось.

Но вообще это вкусовщина, сам использовал NTFS пока альтернативы не было. А сейчас следую стандартам принятым индустрией, согласно которым ФС для сменных внешних носителей exFAT, по умолчанию.

А сейчас следую стандартам принятым индустрией, согласно которым ФС для сменных внешних носителей exFAT, по умолчанию.

…а стандартная ОС, принятая индустрией - Windows 10. Я привык думать головой, а не смотреть что там напринимала индустрия.

Например, время копирования часто рассчитывается немножко по-дебильному: сначала показывает субсветовую скорость копирования, 5G нервно курит в сторонке, потом процентах на 20% шкала останаливается и все начинает до-о-о-лго висеть на одном месте. Иногда даже отвисает.

Это из за кеширования. Сначала он тебе показывает скорость записи в файловый кэш, а потом ждёт окончания сброса кэша на носитель. Функция рисующая шкалу не может отличить запись в кэш от записи на носитель, она на текущую скорость смотрит и пытается усреднять и прогнозировать. А она скачет, в кэш пишется ультрабыстро, пока он не заполнится, а дальше уже от носителя и интерфейса зависит. Монтируй в синхронном режиме, будет писать равномерно. IMHO c USB3 и современными «быстрыми» флешками это уже не так мучительно как раньше, да и система больше не встаёт раком при записи на медленный носитель (хотя у меня и раньше не вставала, но куча народу жаловалась на мифический баг 12309, лично я его за двадцать с лишним лет ни разу не видел).

«теперь питание компьютера можно отключить». круто, то, что нужно в 21 веке.

«теперь питание компьютера можно отключить». круто, то, что нужно в 21 веке.

Монтируй в синхронном режиме и выдёргивай сразу как записалось, в чём проблема? В винде по умолчанию именно так. Только людям это не нравится, они сами включают кеширование в настройках, а потом иногда бомбят и плачут. А в линуксах это по разному. Мой дистрибутив всё сменное монтирует по умолчанию синхронно. В других дистрибутивах может быть по другому, но в любом случае это настраивается, как и в винде.

Функция рисующая шкалу не может отличить запись в кэш от записи на носитель

Ну то есть немножко по-дебильному :-) Хотя за ликбез спасибо.

Монтируй в синхронном режиме, будет писать равномерно

Я уже на Гноме и копирование меня устраивает. Шкала не тупит, заполняется равномерно, по индикатору легко можно понять записалось или нет.

Функция рисующая шкалу не может отличить запись в кэш от записи на носитель

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

это тебе ещё про внутренние кеши буферы носителей не сказали

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

это тебе ещё про внутренние буферы носителей не сказали

Сказали: Гарантирует ли Linux 100% сохранность файлов при копировании? (комментарий)

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

мне показалось там речь шла о файловом кеше