Вопросы Теги

Может смолить archiver, заполняют нулями файл?

У Вас есть проблемы с заключением в кавычки, потому что Вы называете popen с командной строкой, которая передается оболочке. Строковый синтаксический анализатор Ruby или ест двойные кавычки или ест обратную косую черту. Можно или назвать popen с массивом строк, который обойдет оболочку, или можно записать emacs foo\\ bar который выйдет из обратной косой черты, которую Вы хотите, чтобы Ruby уехал в оболочку для наблюдения.

2
04.03.2013, 15:23
2 ответа

Наиболее вероятная проблема состоит в том, что tar был поврежден, в то время как он создавался. Из-за пути формат tar определяется (так как он предназначается, чтобы быть потоковой передачей archiver), он должен определить длину файла заранее. Это записывает эту длину в заголовке tar, затем начинает писать содержание файла в файл tar. Если по некоторым причинам будет ошибка при чтении файла, или если файл уменьшится, в то время как это архивируется, это заполнит, АННУЛИРУЕТ. Это необходимо так, чтобы длина, указанная в заголовке, была все еще допустима после извлечения (это не может возвратиться и изменить заголовок из-за его характера потоковой передачи, и если бы это не заполняло файл ПУСТЫМИ УКАЗАТЕЛЯМИ, которые вызвали бы ошибку при извлечении следующего файла в архиве).

Кроме того, так как tar имеет дело с двоичными данными (он не имеет никакого "текстового" режима), не должно быть никакой проблемы (что касается tar) с различной кодировкой языка.

1
27.01.2020, 22:07
  • 1
    я воспроизвел подобную проблему с SD-картой на OSX. cp отказанный для копирования файлов с SD-карты (цитирующий ошибку ввода-вывода), но tar счастливо появившийся, чтобы смолить файлы. Я предполагаю tar слишком отказоустойчиво и создал файл tar, даже при том, что это было бесполезно, так как все извлеченные файлы были чисты 0, подтвержденный с od -t x1 files*. –  Mark Lakata 12.01.2018, 02:02

Вы уверены, что все байты равны 0x00? В этом случае Ваши файлы не содержат информации вообще (за исключением их размера). Ни одна программа не могла возможно сохранить или передать информацию как все нули (если это не является телепатическим).

То, что может произойти, - то, что файл имеет переменный текст и нулевые байты. Вот то, что это означало бы: Вы получили файлы, которые содержат unicode текст, закодированный как UTF-16 (или почти эквивалент). Каждый символ поднимает 16 битов (два байта). Unicode присваивает английские буквы и символы к их коду символа ASCII, что означает что, например, буква A шестнадцатеричный 41 в ASCII и 00 41 в Unicode. Результат состоит в том, что, если Вы выписываете "Привет" как UTF-16 и читаете его в как 8-разрядный текст, Вы будете видеть это:

\0 H \0 e \0 l \0 l \0 o

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

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

2
27.01.2020, 22:07
  • 1
    Спасибо за ответ, но они - конечно, нуль. Должна быть проблема на моем сайте коллеги... А-ч –  Honza 04.03.2013, 16:10
  • 2
    , я сказал бы, что это определенно должно быть. Удача с ним затем. –  alexis 04.03.2013, 16:12
  • 3
    Вот почему это звонило Telepathic ARchiver ... или короткий TAR ... это должно знать! –  0xC0000022L 04.03.2013, 16:56
  • 4
    @0xC0000022L В этом случае, я предпочел бы его просто, сохранил число нулевых байтов. Сократил бы решительно на размерах резервных копий. –  a CVn 04.03.2013, 17:08
  • 5
    @MichaelKjörling Unix: tar производит длинные потоки 0 байтов, gzip преобразовывает их в количество. –  Gilles 'SO- stop being evil' 05.03.2013, 01:10

Теги

Похожие вопросы