Я скачал файл с сервера, а он отказывается распаковываться (запускаться). Кто виноват, и что делать?
Причин, по которым скаченный файл может отказаться распаковываться (запускаться), – множество. Кстати, не факт, что файл действительно полностью скачался – многие серверы не поддерживают функцию определения размера качаемого файла и, если соединение внезапно разорвется, для качальщика это будет выглядеть неотличимо от конца файла. В такой ситуации определить действительный конец невозможно – попробуйте скачать файл еще раз – если получится тот же самый размер, скорее всего, файл был получен целиком, ведь маловероятно чтобы соединение дважды разрывалось на одном и том же месте, хотя и такое в жизни бывает.
Другой "тонкий" момент– при скачивании файла с ftp-сервера в режиме "ASCII" все символы конца строки передаваемого файла принудительно замещаются сервером двухбуквенной последовательностью "возврат каретки, конец строки" согласно стандарту виртуальных терминалов. Подобная мера необходима для согласования различных платформ, сред и операционных систем, т.к. в силу исторических причин все они имеют собственный взгляд на формат завершения строки. Например, в текстовом файле, созданным редактором UNIX, каждая строка традиционно завершается символом с кодом 0xA, что "переваривает" далеко не всякий Windows (DOS) редактор, ожидающий увидеть в конце строки комбинацию 0xD 0xA. Поэтому, приведение содержимого файла, сливаемого с ftp-сервера, к единому стандарту вполне разумно и полезно, за исключением нетекстовых файлов (архивов, исполняемых и т.д.) бесцеремонное вмешательство во внутреннюю структуру которых, скорее всего, приведет к их необратимой порче. О том, как выключить режим "ASCII" см. ответ на вопрос "subQ: Что такое режим ASCII и как его отключить в моем ftp-клиенте?"
При сливании файла через Proxy часто возникает следующая проблема: при обрыве соединения с удаленным сервером Proxy пытается сообщить пользователю об ошибке, дописывая в конец файла собственное сообщение. Если "качальщик" не распознает такой ситуации и при докачке файла начнет записывать новые данные в его конец – файл окажется безнадежно искореженным застрявшем в его теле сообщением. Во избежание подобных казусов некоторые "качальщики" (GetRight, ReGet) после каждого обрыва отрезают некоторый кусок от "хвоста" файла – достаточно длинный для того, чтобы гарантировано вместить в себя зловредное сообщение об ошибке. Как правило, для этого достаточно двух – четырех килобайт, т.е. теряется всего лишь несколько секунд перекачки на каждый разрыв, что вполне приемлемо. Однако в излишнем рвении к оптимизации, некоторые разработчики не задействуют такой режим по умолчанию, и его приходится включать принудительно (ReGet к таковым не относится). Как именно это сделать – читайте в прилагаемой к "качальщику" документации. Универсальных решений и даже устоявшихся названий этой опции не существует.
Наконец, файл может быть поврежден на самом сервере или же стоит "битый" сервер, калечащий сливаемые файлы. В качестве примера можно привести сервер kpnc.lib.ru, на котором находится сайт автора – с него невозможно слить ни один двоичный файл, в том числе и файл, содержащий заархивированное содержимое компакт-диска, прилагаемого к книге "Техника и философия хакерских атак" Криса Касперски.
Родственные вопросы:
Что такое режим ASCII и как его отключить в моем ftp-клиенте? (следующий)
