Ты не можешь увидеть дамп каталога, потому что это каталог :))

Посмотри так и быть....

$ od -cb . 0000000 4 ; . \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 064 073 056 000 000 000 000 000 000 000 000 000 000 000 000 000 0000020 273 ( . . \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 273 050 056 056 000 000 000 000 000 000 000 000 000 000 000 000 0000040 252 ; r e c i p e s \0 \0 \0 \0 \0 \0 \0 252 073 162 145 143 151 160 145 163 000 000 000 000 000 000 000 0000060 230 = j u n k \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 230 075 152 165 156 153 000 000 000 000 000 000 000 000 000 000 0000100 $

затарь и посмотри, делов то

Дружище JOY

Дело в том что пример взят из книги: Керниган, Пайк - UNIX. Программное окружение ,проблема в том, что ни в Debian ни в Arch, как то это не работает.. ВОПРОС -->>почему?

Это «риторический вопрос» , а вообще да «затарь и посмотри»

ВОПРОС -->>почему?

А почему, собственно, должно?

А почему, собственно, должно?

Ну как, вот взяли и сломали Unix, где всё есть файл. Причём, сказать что «в Linux» нельзя, когда-то это и в Linux работало. Чем каталог не спец файл? Кому помешало возможность делать его read(2)? open же даёт.

Ну как, вот взяли и сломали Unix, где всё есть файл.

Чойта? В символьных устройствах нельзя делать seek. Так что ограничения на операции уже были, они не появились ниоткуда.

Кому помешало возможность делать его read(2)?

В некоторых ФС нет как такового логически сплошного куска данных, которые можно было бы вернуть. Да и зачем? Что ты там хотел увидеть?

Чойта? В символьных устройствах нельзя делать seek

И что? На то и спец файлы, там по определению набор сисколов ограничен. Что там seek, в каталог никогда нельзя было делать write. "." и ".." 30 лет назад делали тоже mknod-ом.

такового логически сплошного куска данных,

Вообще-то для того ОС и существует, чтобы блоки собирать в логические конструкции.

Что ты там хотел увидеть?

Я хотел отсутствие бардака, не было никакой необходимости в отдельном сисколе readdir, обходились же 30 лет без него. Вам волю дать, так вы на каждый файл из /proc/* свой сискол придумаете...

Ну как, вот взяли и сломали Unix, где всё есть файл.

POSIX сломали? Нет.

А так в линуксе больше «всё есть файл», чем в тех же BSD.

В разных фс разные структуры каталога, с одной фс для всего на венфак.

А так в линуксе больше «всё есть файл»

В линуксе больше «всё есть ФС».

Я хотел отсутствие бардака, не было никакой необходимости в отдельном сисколе readdir ...

Ты сейчас описал, как всё плохо, но не описал, как сделать хорошо. Если хочешь дальше на эту тему дискутировать, напиши, пожалуйста, детальное описание того, что должен возвращать read для директории. Ещё продумай, что там с seek, и вообще, что остальные системные вызовы возвращают.

В линуксе больше «всё есть ФС».

Одно другому не мешает :)

Правда, с распространением всех этих специальных ФС становится всё труднее читать вывод mount без фильтров.

А так в линуксе больше «всё есть файл», чем в тех же BSD.

Смотря что считать за BSD, если BSD4 - то там как с каталогами то что описал. Вон в Minix-е и Solaris-е, как наследницам можно было без дурацкого BSD-стека с новыми набором кучей сисколов socket/listen/accept/bind и т д обходиться чисто Unix-овыми open(«/dev/tcp») ioctl(BIND/LISTEN/ACCEPT...) и так далее.

А в BSD однако «все впорядке», а LINUX как извесно не UNIX :) спасибо всем кому было интересно и не очень!

$ od -cb . 0000000 036 W \v \0 \f \0 004 001 . \0 \0 \0 035 W \v \0 036 127 013 000 014 000 004 001 056 000 000 000 035 127 013 000 0000020 \f \0 004 002 . . \0 \0 037 W \v \0 024 \0 \b \v 014 000 004 002 056 056 000 000 037 127 013 000 024 000 010 013 0000040 . l o g i n _ c o n f \0 W \v \0 056 154 157 147 151 156 137 143 157 156 146 000 040 127 013 000 0000060 020 \0 \b 006 . c s h r c \0 377 ! W \v \0 020 000 010 006 056 143 163 150 162 143 000 377 041 127 013 000 0000100 020 \0 \b \a . m a i l r c \0 " W \v \0 020 000 010 007 056 155 141 151 154 162 143 000 042 127 013 000 0000120 024 \0 \b \b . p r o f i l e \0 246 020 201 .............. $ $ uname -a -sh: $: not found $ FreeBSD FreeBSD 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 $ $

В линуксе всё через один socketcall))

http://man7.org/linux/man-pages/man2/socketcall.2.html

On a some architectures — for example, x86-64 and ARM—there is no socketcall() system call

А теперь проделай то же самое на tmpfs :)

fdescfs(5) - file-descriptor file system

procfs и fdescfs там есть, костыльной sysfs не нужен, но при необходимости можно и его воткнуть. Но вы продолжайте, продолжайте )

% whatis procfs linsysfs fdescfs 
fdescfs(5) - file-descriptor file system
linsysfs(5) - Linux system file system
procfs(5) - process file system

Поскольку вы просили то пожалуста;

root@FreeBSD:~ # mount -t tmpfs -o rw,mode=1777,size=4096M tmpfs /tmp

root@FreeBSD:~ # cd /tmp

root@FreeBSD:/tmp # od -cb .

od: .: Is a directory

root@FreeBSD:/tmp #

.......Интерфейсом работы с файлами является vnode (от virtual inode — виртуальный индексный дескриптор). .....Структура данных vnode одинакова для всех файлов, независимо от типа реальной файловой системы, где фактически располагается файл. Данные vnode содержат информацию, необходимую для работы виртуальной файловой системы, а также неизменные характеристики файла, например, такие как тип файла.

Уважаемый, а вы не могли бы в кратце =в чем мораль= , возможно есть какие то опции для «tmpfs»

https://www.freebsd.org/cgi/man.cgi?query=read&sektion=2&manpath=free...

[EISDIR] The file descriptor is associated with a directory residing on a file system that does not allow regular read operations on directories (e.g. NFS).

/usr/src/sys/fs/tmpfs/tmpfs_vnops.c
static int
tmpfs_read(struct vop_read_args *v)
{
        struct vnode *vp;
        struct uio *uio;
        struct tmpfs_node *node;

        vp = v->a_vp;
        if (vp->v_type != VREG)
                return (EISDIR);

Coбственно, как тут уже упоминалось — нужна поддержка ФС.