32

In the past, I learned that in Linux/UNIX file systems, directories are just files, which contain the filenames and inode numbers of the files inside the directory.

Is there a simple way to see the content of a directory? I mean the way the files names and inodes are stored/organized.

I'm not looking for ls, find or something similiar. I also don't want to see the content of the files inside a directory. I want to see the implementation of the directories. If every directory is just a text file with some content, maybe a simple way exists to see the content of this text file.

In the bash in Linux it is not possible to do a cat folder. The output is just Is a directory.

Update The question How does one inspect the directory structure information of a unix/linux file? addresses the same issue but it has no helpful solution like the one from mjturner.

5
  • I don't think vi <folder> suits your needs? Just mentioning it
    – Lenniey
    Jul 17, 2015 at 7:26
  • vim <DIR> Is this what you want?
    – jijinp
    Jul 17, 2015 at 7:27
  • For starters take a look at the stat command. stat folder.
    – slm
    Jul 17, 2015 at 8:10
  • 2
    I believe that historically cat would have worked. But that approach was obsolete decades ago. I don't know of any direct way to see the actual file system storage. Instead there are new system calls to return the information in a standardized format which remains the same regardless of which underlying file system is being used.
    – kasperd
    Jul 17, 2015 at 13:04

3 Answers 3

40

The tool to display inode detail for a filesystem will be filesystem specific. For the ext2, ext3, ext4 filesystems (the most common Linux filesystems), you can use debugfs, for XFS xfs_db, for ZFS zdb. For btrfs some information is available using the btrfs command.

For example, to explore a directory on an ext4 filesystem (in this case / is dev/sda1):

# ls src
Animation.js    Map.js        MarkerCluster.js    ScriptsUtil.js
Directions.js   MapTypeId.js  markerclusterer.js  TravelMode.js
library.js      MapUtils.js   Polygon.js          UnitSystem.js
loadScripts.js  Marker.js     Polyline.js         Waypoint.js

# ls -lid src
664488 drwxrwxrwx 2 vagrant vagrant 4096 Jul 15 13:24 src

# debugfs /dev/sda1
debugfs: imap <664488>
Inode 664488 is part of block group 81
        located at block 2622042, offset 0x0700
debugfs: dump src src.out
debugfs: quit

# od -c src.out
0000000 250   #  \n  \0  \f  \0 001 002   .  \0  \0  \0 204 030  \n  \0
0000020  \f  \0 002 002   .   .  \0  \0 251   #  \n  \0 024  \0  \f 001
0000040   A   n   i   m   a   t   i   o   n   .   j   s 252   #  \n  \0
0000060 030  \0  \r 001   D   i   r   e   c   t   i   o   n   s   .   j
0000100   s  \0  \0  \0 253   #  \n  \0 024  \0  \n 001   l   i   b   r
0000120   a   r   y   .   j   s  \0  \0 254   #  \n  \0 030  \0 016 001
0000140   l   o   a   d   S   c   r   i   p   t   s   .   j   s  \0  \0
0000160 255   #  \n  \0 020  \0 006 001   M   a   p   .   j   s  \0  \0
0000200 256   #  \n  \0 024  \0  \f 001   M   a   p   T   y   p   e   I
0000220   d   .   j   s 257   #  \n  \0 024  \0  \v 001   M   a   p   U
0000240   t   i   l   s   .   j   s  \0 260   #  \n  \0 024  \0  \t 001
0000260   M   a   r   k   e   r   .   j   s  \0  \0  \0 261   #  \n  \0
0000300 030  \0 020 001   M   a   r   k   e   r   C   l   u   s   t   e
0000320   r   .   j   s 262   #  \n  \0 034  \0 022 001   m   a   r   k
0000340   e   r   c   l   u   s   t   e   r   e   r   .   j   s  \0  \0
0000360 263   #  \n  \0 024  \0  \n 001   P   o   l   y   g   o   n   .
0000400   j   s  \0  \0 264   #  \n  \0 024  \0  \v 001   P   o   l   y
0000420   l   i   n   e   .   j   s  \0 265   #  \n  \0 030  \0 016 001
0000440   S   c   r   i   p   t   s   U   t   i   l   .   j   s  \0  \0
0000460 266   #  \n  \0 030  \0  \r 001   T   r   a   v   e   l   M   o
0000500   d   e   .   j   s  \0  \0  \0 267   #  \n  \0 030  \0  \r 001
0000520   U   n   i   t   S   y   s   t   e   m   .   j   s  \0  \0  \0
0000540 270   #  \n  \0 240 016  \v 001   W   a   y   p   o   i   n   t
0000560   .   j   s  \0 305 031  \n  \0 214 016 022 001   .   U   n   i
0000600   t   S   y   s   t   e   m   .   j   s   .   s   w   p  \0  \0
0000620 312 031  \n  \0   p 016 022 001   .   U   n   i   t   S   y   s
0000640   t   e   m   .   j   s   .   s   w   x  \0  \0  \0  \0  \0  \0
0000660  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

In the above, we start by finding the inode of directory src (664488) and then dump its contents into file src.out and then display that using od. As you can see, the contents of all of the files in that directory (Animation.js, etc.) are visible in the dump.

This is just a start - see the debugfs manual page or type help within debugfs for more information.

If you're using ext4, you can find more information about the structure and layout of directory entries in the kernel documentation.

2
  • This is great answer. Thanks a lot! Now I try to investigate how I can show the inode numbers in this output in decimal notation. I think the values besides the file names in the output are the inode numbers. Or am I wrong?
    – Neverland
    Jul 17, 2015 at 10:30
  • @Neverland Yes, those are the inode numbers. They're probably clearer if you use od -x to dump the directory entry file.
    – mjturner
    Jul 17, 2015 at 13:10
0

You can use your programming language of choice, open the directory as if it was a file and read bytes from the resulting file handle. That's not going to tell you much, though, since it will just be garbage (with a few recognizable strings in it) as long as you don't know how it's organized. How it is organized is pretty much an implementation issue for the file system in question. If you want to look into these things in depth, I suggest you start by reading man dirent.h. That should be enough to point you further toward what strikes your fancy.

3
  • 3
    Linux doesn't allow this... and I think most systems that do return the data in a unified format rather than whatever's actually in the filesystem.
    – Random832
    Jul 17, 2015 at 12:19
  • 2
    This used to be possible back in the (very) old days. You can see evidence of this in K&R 2nd Edn. However, it is no longer possible; it hasn't been possible for most of this millennium. Jul 17, 2015 at 12:40
  • This is possible, but unnecessary, under Unix systems - you can just use cat to display the contents if you like but hd (Unix equivalent of xxd) is probably more useful. I've noticed that Linux-based systems return an error if you open a directory file for reading, on the assumption it's a mistake. "By stopping stupid people doing stupid things, you also stop clever people doing clever things".
    – FJL
    Feb 6, 2018 at 16:57
0

You can try (partition is an example).

sudo debugfs /dev/xvda1                 

use dump to write inode data to a file.

sudo dumpe2fs /dev/xvda1

man is your friend, these should give you some ideas.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .