Что действительно 'неожиданно исправляет концы в середине строки', средней?

Причина, что системы Linux/Unix не имеют восстановить после удаления основ от пути большинством файловых систем, хранит их информацию. Метаинформация файла все хранится перед диском со ссылками на inodes на остальной части диска. Как правило, большинство файловых систем выделяет 10 блоков файлу в этой метаобласти. Первые 7 относятся к первым 7 inodes. 8-е и 9-е движение к спискам inodes (вдвойне связанные блоки) и 10-е движения к списку списков списков (трижды связанные блоки). Это варьируется от файловой системы до файловой системы (ext4, jfs, xfs, и т.д.), но эти списки блоков могут обычно обращаться к размерам файла где угодно от 2 ГБ до нескольких ТБ.

Но потому что вся эта информация хранится перед диском, когда файл стирается, нет никакого способа сослаться на inodes на диске к тому, какие метаданные они используют для принадлежности. По контрасту FAT32 и NTFS на самом деле снабжают некоторую информацию заголовка самими файлами, помогающими определить, какой файл ряд использования блоков для принадлежности (пока то пространство еще не было освобождено более новыми файлами). В работе Linux при удалении чего-то это - почти всегда первая вещь, которая будет сразу перезаписана новыми данными для эффективности.

14
30.08.2010, 18:07
3 ответа

Сообщение относится к Ломтю 16.

Это обсуждение GitHub, вероятно, связано с Вашей проблемой.

Это о патче, неожиданно заканчивает в середине сообщений строки из-за CRLF (возврат каретки, перевод строки) проблемы, когда сгенерированные diffs мерзавца используются с патчем.

Заключить заключение в кавычки:

[..] мерзавец может быть очень требователен в отношении окончаний строки. Вы находитесь на окнах или нет? Во всяком случае необходимо, вероятно, установить autocrlf в конфигурации мерзавца. Если Вы находитесь на окнах, Вы хотите "верный", если Вы находитесь на Mac или Linux, необходимо использовать "вход" [..]

В статье Dealing с окончаниями строки GitHub детализирует вышеупомянутый оператор.

11
27.01.2020, 19:51
  • 1
    Это должно быть отмечено, корреспондент спросил это, это плохо - заканчивающийся посреди строки, не проблема - просто предупреждение. –  Ross 10.04.2014, 19:05

Если вы не используете git (комментарий @ maxslepzig касался использования патча в контексте git ), попробуйте добавить возврат каретки в конец файла. Я сделал это, и патч принял мой патч.

3
27.01.2020, 19:51

Чтобы добавить к этому очень старому обсуждению:

Проблема, приводящая к предупреждению, отмеченному OP, обычно вызвана проблемами с окончаниями строк.

patchтребует перевод строки в конце (LF ), чтобы определить конец файла (и предупреждает об объединенном diff, который мог быть случайно усечен)

  1. Добавить правильный перевод строки, не открывая файл для редактирования (, что может изменить окончания строк или удалить конечные строки/пробелы в зависимости от настроек вашего редактора )вы можете сделать что-то простое, например:

    echo -e "\n" >> YOURPATCHFILE

    Это добавляет символ перевода строки в конец файла без внесения каких-либо других изменений.

  2. Если ваш патч-файл уже странный или вы хотите пройти сразу несколько возможных исправлений, вы можете исправить многие проблемы с кодировкой (в ascii ), включая окончания строк (CR или CRLF в LF):

    dos2unix -k YOURPATCHFILE

    Возможно, вам придется установить бинарный файл dos2unix из менеджера пакетов вашей ОС; то есть

    • На базе Debian/Ubuntu:sudo apt install dos2unix
    • Fedora/RHEL/CentOS:sudo yum install dos2unix
    • MacOS (с пивом):brew install dos2unix
3
27.01.2020, 19:51

Теги

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