LINUXTALKS.CO

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

 ,


0

2

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

Существует ли в природе FTP клиент который может проверить не битый ли файл после скачавания? Или придётся городить скриптулю для таких целей?

Сервер поддерживает XCRC команду.

★★★★★★

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

deep-purple    
★★★★★★★★★
Android / Firefox
Ответ на: комментарий от deep-purple

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

cocucka    
★★★★★★
Windows / Firefox
Ответ на: комментарий от cocucka

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

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

torvn77    
★★★★★★
Android / Chrome
Ответ на: комментарий от cocucka

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

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

torvn77    
★★★★★★
Android / Chrome
Ответ на: комментарий от torvn77

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

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

torvn77    
★★★★★★
Android / Chrome
Ответ на: комментарий от torvn77

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

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

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

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

xtraeft    
★★★★★
Android / Firefox
Ответ на: комментарий от deep-purple

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

cocucka    
★★★★★★
Ubuntu / Firefox
Ответ на: комментарий от xtraeft

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

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

torvn77    
★★★★★★
Linux / Chrome
Ответ на: комментарий от torvn77

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

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

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

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

cocucka    
★★★★★★
Ubuntu / Firefox
Ответ на: комментарий от cocucka

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

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

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

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

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

torvn77    
★★★★★★
Последнее исправление: torvn77 (всего исправлений: 1)

Linux / Chrome
Ответ на: комментарий от torvn77

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

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

TheAnonymous    
★★★★★★★★★
Linux / Firefox
Ответ на: комментарий от torvn77

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

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

cocucka    
★★★★★★
Windows / Firefox
Ответ на: комментарий от cocucka

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

torvn77    
★★★★★★
Linux / Chrome
Ответ на: комментарий от torvn77

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

xtraeft    
★★★★★
Android / Firefox
Ответ на: комментарий от xtraeft

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

torvn77    
★★★★★★
Последнее исправление: torvn77 (всего исправлений: 1)

Linux / Chrome
Ответ на: комментарий от torvn77

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

xtraeft    
★★★★★
Android / Firefox
Ответ на: комментарий от torvn77

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

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

xtraeft    
★★★★★
Android / Firefox
Ответ на: комментарий от xtraeft

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

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

torvn77    
★★★★★★
Android / Chrome
Ответ на: комментарий от xtraeft

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

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

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

torvn77    
★★★★★★
Последнее исправление: torvn77 (всего исправлений: 1)

Android / Chrome
Ответ на: комментарий от xtraeft

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

torvn77    
★★★★★★
Последнее исправление: torvn77 (всего исправлений: 1)

Android / Chrome
Ответ на: комментарий от xtraeft

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

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

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

torvn77    
★★★★★★
Последнее исправление: torvn77 (всего исправлений: 2)

Linux / Chrome
Ответ на: комментарий от xtraeft

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

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

TheAnonymous    
★★★★★★★★★
Последнее исправление: TheAnonymous (всего исправлений: 2)

Linux / Firefox
Ответ на: комментарий от TheAnonymous

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

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

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

torvn77    
★★★★★★
Android / Chrome
Ответ на: комментарий от torvn77

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

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

TheAnonymous    
★★★★★★★★★
Linux / Firefox
Ответ на: комментарий от TheAnonymous

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

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

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

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

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

torvn77    
★★★★★★
Linux / Chrome
Ответ на: комментарий от torvn77

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

Minona    
★★★★
Последнее исправление: Minona (всего исправлений: 1)

Windows / Yandex
Ответ на: комментарий от Minona

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

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

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

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

torvn77    
★★★★★★
Android / Chrome
Ответ на: комментарий от Minona

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

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

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

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

torvn77    
★★★★★★
Последнее исправление: torvn77 (всего исправлений: 2)

Android / Chrome
Ответ на: комментарий от torvn77

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

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

Minona    
★★★★
Windows / Yandex
Ответ на: комментарий от Minona

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

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

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

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

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

Minona    
★★★★
Windows / Yandex
Ответ на: комментарий от Minona

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

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

torvn77    
★★★★★★
Последнее исправление: torvn77 (всего исправлений: 1)

Linux / Chrome

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

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

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

Aber    
★★★★★
Ubuntu / Firefox
Ответ на: комментарий от Minona

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

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

torvn77    
★★★★★★
Linux / Chrome
Ответ на: комментарий от torvn77

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

Minona    
★★★★
Windows / Yandex
Ответ на: комментарий от Minona

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

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

torvn77    
★★★★★★
Последнее исправление: torvn77 (всего исправлений: 1)

Android / Chrome
Ответ на: комментарий от Minona

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

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

torvn77    
★★★★★★
Android / Chrome
Ответ на: комментарий от torvn77

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

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

Minona    
★★★★
Последнее исправление: Minona (всего исправлений: 1)

Windows / Yandex
Ответ на: комментарий от Minona

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

torvn77    
★★★★★★
Android / Chrome
Ответ на: комментарий от Minona

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

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

torvn77    
★★★★★★
Android / Chrome
Ответ на: комментарий от torvn77

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

Minona    
★★★★
Windows / Yandex
Ответ на: комментарий от torvn77

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

Minona    
★★★★
Windows / Yandex
Ответ на: комментарий от Minona

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

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

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

Ты тупишь:

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

Android / Chrome
Ограничение на отправку комментариев: только для зарегистрированных пользователей, score>=90