Определение, является ли объект файловой системы procfs/sysfs/etc. “виртуальный файл”, который не сообщает о его длине правильно

Я говорю на основе опыта только с deb/dpkg, но не, пока Checkinstall преуспевает в том, чтобы создать deb/rpm, нет никаких побочных эффектов от установки этого (существуют сценарии, где это не создаст пакет).

Конечно, checkinstall действительно не знает о зависимостях, таким образом, необходимо будет иметь их в наличии, если Вы планируете установить пакет где-нибудь. Иначе функциональность удаления работает точно, как предназначено.

Если это не работает, и Вы опасаетесь некоторого пакета, chroot является (относительно) быстрым и безболезненным способом испытать его; виртуальная машина еще лучше, но требует большего количества времени установки и ресурсов, если у Вас нет того, который копирует Вашу систему, лежащую вокруг.

4
22.06.2013, 01:56
2 ответа

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

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

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

Надежда, которая помогает.

3
27.01.2020, 20:52
  • 1
    Понимание о файлах с 0 длинами является блестящим. Хотя Hauke ответил на вопрос, я спросил (который, вероятно, более ценен будущим читателям), Вы решили мою проблему. –  librik 22.06.2013, 08:19

Проверка пути является только почти лучшей идеей. Можно проверить файловую систему (устройство) вместо этого: st_dev=makedev(0, 14). Если главное число 0 затем, это proc, sys и т.п.

Даже ядро не может быть уверено в природе файла. Предположите, что FUSE монтируется, который содержит части /proc. Ядро приняло бы нормальную файловую систему, тогда как это - псевдо файловая система с проблемами, которых Вы хотите избежать.

Но если Вы знаете это SEEK_END не работает, почему Вы не используете это для теста?

3
27.01.2020, 20:52
  • 1
    Спасибо! я предполагаю, что Вы подразумеваете, что я использовал бы major(st.st_dev) == 0? Но Ваша точка о частичном монтировании хорошо взята; вот почему я надеялся, что было возможно спросить файл непосредственно. В ответе на Ваш последний вопрос: SEEK_END ищет на начало данных в псевдофайле, а не конце, который является неправильным, но согласовывается с (также неправильный) размер 0. Таким образом, Вы не можете использовать его для различения псевдофайла из регулярного пустого файла. –  librik 22.06.2013, 03:38
  • 2
    Гм, я не могу найти документацию, которую идентификатор основного устройства 0 означает "proc, sys, и т.п.", хотя экспериментирование на машинах Linux демонстрирует это. Вы могли указать на меня в правильном направлении? –  librik 22.06.2013, 08:24
  • 3

Теги

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