FTP клиент с поддержкой проверки целостности скачанного файла

Филезилла – неудавшиеся попытки скидывает в отдельную вкладку. Пойдет?

Не, я как раз ей и пользуюсь. Она их успешно битыми скачивает, целостность не проверяет.

Даже если там есть чексумма на весь фаил, то это ведь всё равно не позволит выявить ошибку, так какой смысл проверять чексумму в клиенте?

И это не говоря о том, что файл может быть битым прямо на сервере.

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

Ну и после скачивания не забудь
sync && sync && sync

Ну и после скачивания не забудь
sync && sync && sync

То есть в смысле после сохранения на диск.

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

Канеш, ведь проблема точно в диске, а не в сети или сервере.

Ну и после скачивания не забудь
sync && sync && sync

Мало, надо раз 5-6 минимум, иначе оно не докачается.

Вона чо пишут: https://stackoverflow.com/questions/30626006/ftp-copy-check-integrity-and-delete

Так что без плагинов или самописной портянки не получится.

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

Канеш, ведь проблема точно в диске, а не в сети или сервере.

Так или иначе метод работает.

Даже если там есть чексумма на весь фаил, то это ведь всё равно не позволит выявить ошибку, так какой смысл проверять чексумму в клиенте?

В смысле не позволит? Сервак репортит чексумму А, а клиент подсчитал, что она Б – файл повредился при передаче, надо перекачать. Так все делают, например, пакетные менеджеры проверяют чексуммы пакетов.

И это не говоря о том, что файл может быть битым прямо на сервере.

Это отдельный случай. Тогда бы мне перекачка не помогала.

В смысле не позволит?

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

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

И как бы тебе смешно не было, опробуй вот этот рецепт:

Сначала скачиваешь на tmpfs, и только потом из tmpfs сохраняешь на диск, тогда ошибок либо не будет вообще, либо существенно меньше.
Ну и после скачивания не забудь
sync && sync && sync

торрентоподобные протоколы

необязательно, rsync --inplace например тоже докачает дельту вместо целого файла

Я о том, чтобы качать и проверять файл частями, а не о распределённости.

Ну если в этом смысле, то да

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

Если бы это был мой сервак, то я бы не спрашивал как подпереть костылями протокол который старше меня, а просто заюзал бы современные решения.

Ну тогда опробуй рецепт с tmpfs.

Какая разница, куда ты льешь файл - в память или на диск? Мне интересен ход твоих мыслей.

Это практическое наблюдение, причём у негоесть и более старый вариант: изначально я так копировал файл с одного винчестера на другой, прямое копирование с ошибками, через tmpfs без ошибок.
Причём на самых разных материнках и ОС.
Но естественно это заметно на файлах большого размера, в несколько сотен мегабайт и более.

Я на лоре на днях читал утверждение человека, мол если терабайт торрентов перенести с диска на диск и перехешировать, то будет фейл. Это был ты, или вас таких несколько?

копировал файл с одного винчестера на другой, прямое копирование с ошибками

Так у тебя диски сдохшие. Как это относится к вопросу опчика?

Это был ты, или вас таких несколько?

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

Так у тебя диски сдохшие.

А если копировать через tmpfs то не сдохшие:))

Тебе не кажется странным что подохлость дисков определяется исключительно тем, копировали напрямую или через tmpfs?

Блядь, автор треда что-то писал про сдохшие диски? Иди сделай свой тред и там обсуждай.

Автор треда жаловался что при скачивании предположительно большого объёма информации в скачанной информации оказываются ошибки, чему мой совет вполне соответствует.

Космолучи ещё.

Ты убиваешь любой тех тред, вот честно.

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

Ты убиваешь любой тех тред, вот честно.

Нет, это ты и подобные тебе портят технотреды своим упрямством в непризнании ЭКСПЕРЕМЕНТАЛЬНОГО факта.
Не теории, не домысла, а ФАКТА.

Ну смех смехом (а пихва кверху мехом), у меня когда-то было вот такое
https://www.linux.org.ru/forum/talks/10699146
Скорее всего, что-то программное, т.к. оборудование исправное (и потом такого не было), но хз что это было, то ли ядро (драйвер ФС) как-то глючно работало из-под ксена, может ширус или троян какой, может рептилоиды облучали.
Но факт имел место.

Однако, очевидно, это ненормально. И надо тогда решать эту проблему, а не пытаться придумать костыли (типа вроде через tmpfs копируется) и дальше закрывать глаза.

И надо тогда решать эту проблему, а не пытаться придумать костыли

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

В общем основной риск связан с теми случаями, когда эти два потока проходят через один и тот же аппаратный узел.
Надёжны случаи когда поток один или на худой конец это потоки чтения и встречных потоков записи нет, а вот если будет встречный поток записи то каждый узел через который они проходят будет возможным местом появления ошибки.

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

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

Но при одном потоке в одну строну то драйвер работает корректно.

Вообще я эксперементировал с тем, чтбы обойти этот глюк и уже точно не помню, но вроде получалось получить снижение ошибок вплоть до их отсутствия если накопители были подключены к двум разным контроллерам.
Но тут я уже точно не помню, так как я потом это бросил, так как перегонять данные надо редко, а способ работы через tmpfs прост и надёжен, да и вообще, я изначально покупал ОЗУ из расчёта что у меня там будет tmpfs минимум на 10 ГБ, так что в половине случаев копируемые файлы помещаются на tmpfs целиком, а в половине от оставшейся половины копируемая информация состоит из нескольких файлов, которые можно перенести на накопитель по очереди.

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

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

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

Бредовый совет.
При скачивании/копировании файла он один хрен сначала помещается в кэш, т.е. в ту же ram.
А твой эксперимент либо не правильно поставлен, либо ты не верно интерпретируешь результат, либо в линуксе есть какой-то баг, т.к. я ни разу не сталкивался с таким в винде (при нормальном железе ессно).

При скачивании/копировании файла он один хрен сначала помещается в кэш, т.е. в ту же ram.

Это было мной обнаружено при переброске торрентов объёмом в несколько гигабайт и по этому:

1. Кеш по любому переполнялся.
2. Не ожидая переполнения кеша система начинает писать на диск.

Ну и в любом случае, я не сталкивался с повреждениями информации при копировании всякой мелочи.

либо в линуксе есть какой-то баг,

И в винде точно такой же баг?
Наверное это потому что Майкрософт код Линукса ворует и без проверки и отладки копипастит в свою ОС.

Скорее всего дело в другом, я полагаю что в отличии от процессора чипсет и по схемотехнике, и по исполнению микросхемы делается на как получится, в следствии чего чипсет перегревается при пересылке объёмов больших данных и видимо логические элементы подходят к краю рабочего режима со всеми прследствиями в виде ошибок в передаче информации(crc коды то в бытовых материнках не считают).

П.С. ты отключи в биосе работу pata/sata и посмотри как поменяется его температура.

У меня 3 раза в день заливается на шару бэкап размером 20 гиг.
Ни разу не выявлял повреждение этого файла.

С торрентами был косяк, необъяснимый.
Я удалил в корзину файл, потом восстановил обратно.
В клиенте запустил проверку хешей, так он нашёл ошибки и перекачал эти фрагменты.

У меня 3 раза в день заливается на шару бэкап размером 20 гиг.

1. Тут ключевое слово "на шару", которая в твоём случае заменяет tmpfs.
   (В идеале нужна пересылка данных БЕЗ ПОСРЕДНИКА меджду двумя разделами на одном накопителе)
2. Во вторых и на хосте, и на сервере хранения бекапа у тебя идёт один поток чтения на хосте и один поток записи на сервере.
3. К тому же не удевлюсь что и там и там вместо чипсета БЫТОВОЙ материнки у тебя стоит по райдконтроллеру с SCSI дисками, или софтварный рейд с корекцией ошибок.

1. Так при пересылке с раздела на раздел используется cache, который заменяет tmpfs. Поэтому твой совет с копированием через tmpfs - фигня.
2. И при копировании файла с раздела на раздел также будет один поток.
3. Почти угадал, на серваке обычный SATA, на корзине Adaptec, но без RAID, т.к. там ZFS.

(В идеале нужна пересылка данных БЕЗ ПОСРЕДНИКА меджду двумя разделами на одном накопителе)

Ну копируй через dd c iflag=direct и oflag=direct
Будет без посредников.

используется cache, который заменяет tmpfs

Только вот ОЗУ в системе 1 Гб, а сезон анимесериала весит от трёх до 10 Гб.

XCRC hash command asks the server to perform a cyclic redundancy check using the CRC-32 algorithm

Лол :) 32 битный хеш… очень «надежно».

Я однажды написал штуку которая кешровала тайлы с openstreetmap, написал очень криво и половина тайлов оказывалась битой. Я уже хотел весь кеш дропнуть но потом понял что в PNG есть 32-битный CRC и exiftool позволяет быстро проверить все файлы на битость. И все сработало для 99% файлов, но несколько битых файлов остались, у них хеш сошелся.

И при копировании файла с раздела на раздел также будет один поток.

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

Ну в этом случае твой совет ещё более абсурден, т.к. «предварительно копировать в tmpfs» просто некуда.
Ты этим примером чего хотел показать то? 😏

А какая разница сколько потоков?

Ну в этом случае твой совет ещё более абсурден, т.к.

Эффект обнаружен в эпоху ddr2, а рассуждения по его обходу к сейчас, к концу эпохи ddr3.

А какая разница сколько потоков?

Вычисления и передача данных по кабелю происходит с затратами энергии, по этому если больше потоков - то и больше ЛОКАЛЬНАЯ температура конкретного участка кристалла.

С добрым утром!
Сейчас конец эпохи ddr4.

А тип памяти то какое отношение имеет к твоему совету?
Ты не понимаешь что tmpfs и cache суть та же RAM?

DDR3 ещё не вышла из массовой эксплуатации.

А тип памяти то какое отношение имеет к твоему совету?

Ну найди бытовой компьютер с 16 гигами ddr2 :))

Ну пиздец!
По кабелю в единицу времени передаётся одинаковое количество информации.
И вообще, какие потоки в кабеле? Там оптоволокно многомодовое что-ли?

Да похер сколько RAM.
Если файл не влазит в cache, то он не влезет и в tmpfs.
Вывод: твой совет «предварительно копировать в tmpfs» - хрень!

Я не хочу особо доказывать свою версию причин сбоев при копировании информации,

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

Если файл не влазит в cache, то он не влезет и в tmpfs.

Ты тупишь:

1. Эффект мной обнаружен на системах с небольшим количеством ОЗУ.
2. Система начнёт запись на накопитель не дожидаясь полного заполнения кеша, так что по большому счёту не так и важно как много ОЗУ в системе.