Определение PATH_MAX для файловой системы?

Ответ 1

Поскольку этот вопрос помечен "FUSE"...

Я просто столкнулся с этой проблемой при работе с файловой системой FUSE. Я написал электронное письмо разработчикам FUSE, требуя разъяснений. Ответ от текущего поддерживающего libfuse (январь 2018 г.). Не существует способа указать максимальную длину пути в файловой системе FUSE [driver].

Есть ли способ файловой системы FUSE информировать программное обеспечение, запущенное сверху   о ней о правильной максимальной длине пути?

В настоящий момент нет.

Если нет, должно быть?

Вероятно, да. Патчи приветствуются: -)

Для справки: Полный поток эл. почты

Ответ 2

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

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

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

Ответ 3

В Linux реализация glibc pathconf возвращает постоянное значение времени компиляции PATH_MAX, поэтому для ее корректировки не существует FUSE времени запуска или кто-либо другой. (См. Sysdeps/unix/sysv/linux/pathconf.c, который попадает в sysdeps/posix/pathconf.c.) Ответ на ваш вопрос "Как указать мою файловую систему PATH_MAX?" "Вы не можете. glibc не позволяет вам, а FUSE - просто посланник".

Конечный результат - липкая ситуация. Вот сообщение в блоге, в котором обсуждается код, который делает и не заботится о PATH_MAX. Программное обеспечение, которое опирается на пути, не более, чем PATH_MAX, другие файловые системы, поэтому вам не следует игнорировать PATH_MAX.

В MacOS X (и, возможно, в других BSD): реализация pathconf полностью находится в ядре и может быть заменена на файловую систему. OSXFUSE включает NOOP-версию pathconf, которая должна возвращать обычные константы времени компиляции. Тем не менее, в моих тестах, похоже, есть еще одна функция NOOP на пути, которая возвращает ENXIO, и я не могу заставить pathconf работать.

Бонус: для NAME_MAX, реализовать statfs и установить f_namemax.

Ответ 4

POSIX позволяет _PC_PATH_MAX варьироваться в зависимости от текущего каталога, но это не значит, что системы, которые не меняются, несовместимы.

Настоящая причина существования PATH_MAX заключается в том, что ядро ​​копирует путь в ядерное пространство, прежде чем выполнять какую-либо фактическую работу с ним.

Ваше утверждение о том, что существует PATH_MAX -связанное поле в statvfs, просто неверно. Это связано с NAME_MAX, что совсем другое.

Ответ 5

Мне не хватает других ОС, но imho - это общесистемная настройка, по крайней мере, во FreeBSD 5.2.1

PATH_MAX находится в # 62 sys/syslimits.h

Поскольку static int ufs_pathconf(), который возвращает информацию PATHCONF для UFS FS, использует эту переменную таким образом, как вы указали.

/*
 * Return POSIX pathconf information applicable to ufs filesystems.
 */
int
ufs_pathconf(ap)
    struct vop_pathconf_args /* {
        struct vnode *a_vp;
        int a_name;
        int *a_retval;
    } */ *ap;
{

    switch (ap->a_name) {
    .
    .
    .
    .
    case _PC_PATH_MAX:
        *ap->a_retval = PATH_MAX;
        return (0);
    .
    .
    .
    .

    default:
        return (EINVAL);
    }
    /* NOTREACHED */
}

Ответ 6

PATH_MAX является системной установкой и обычно определяется в pathmax.h как:

define PATH_MAX (pathconf ("/", _PC_PATH_MAX) < 1 ? 1024 \
            : pathconf ("/", _PC_PATH_MAX))