The internal structure of directories is dependent on the filesystem in use. If you want to know precisely what happens, have a look at filesystem implementations.
Basically, in most filesystems, a directory is an associative array between filenames (keys) and inodes numbers (values). Something like this¹:
1167010 .
1158721 ..
1167626 subdir
132651 barfile
132650 bazfile
This list is coded in some – more or less – efficient way inside a chain of (usually) 4KB blocks. Notice that the content of regular files is stored similarly. In the case of directories, there is no point in knowing which size is actually used inside these blocks. That's why the sizes of directories reported by du are multiples of 4KB.
Inodes are there to tie blocks together, forming a single entity, namely a 'file' in the general sense. They are identified by a number which is some kind of address and each one is usually stored as a single, special block.
Management of all this happens in kernel mode. Software just asks for the creation of a directory with a function named int mkdir(const char *pathname, mode_t mode); leading to a system call, and all the rest is performed behind the scenes.
About links structure:
A hard link is not a file, it's just a new directory entry (i.e. a name – inode number association) referring to a preexisting inode entity². This means that the same inode can be accessed from different pathnames. In particular, since metadatas (permissions, ownership, timestamps…) are stored within the inode, these are unique and independent of the pathname chosen to access the file.
A symbolic link is a file and it's distinct from its target. This means that it has its own inode. It used to be handled just like a regular file: the target path was stored in a data block. But now, for efficiency reasons in recent ext filesystems, paths shorter than 60 bytes long are stored within the inode itself (using the fields which would normally be used to store the pointers to data blocks).
—
1. this was obtained using ls -ai1 testdir.
2. whose type must be different than 'directory' nowadays.
The simple answer is that what you want to do is to read the directory file,
with a command like cat ., cat /etc, or cat mydir.
Of course, since this is “raw” data,
you’d want to use a program that’s better suited
to displaying non-ASCII data in a human-friendly way; e.g., hexdump or od.
Unfortunately, as discussed in When did directories stop being readable as files?, most versions of Unix
that were released in the past two decades or so don’t allow this.
So the answer to your question may be
“find a version of Unix that still allows reading directories”.
AIX, most versions of BSD,
and all but the most recent versions of Solaris may qualify.
Finding a Linux that allows it may require the use of a time machine.
Best Answer
stat /bin/sushows on one system:There's the octal representation
4755of all 12 mode bits. The number corresponds to the bits:Where
uuu,gggandoooare the permission bits for the user, group and others. The remaining group (the first one in order) contains the setuid (su), setgid (sg) and sticky (t) bits.The setuid and sticky bits are often not mentioned, since they're zero for most files. They're still there for every file, saved along with the others.
If we really get down to it, some filesystems and interfaces store the file type along the mode bits, in the still-higher bits. The above only accounts for 12 bits, so with a 16-bit field, there's 4 left over. See, for example, the description of
st_modeinstat(2).