File types

File Types

Character and block device files

-rw-r--r-- 1 root root  533 May 26 08:23 /etc/hosts # for comparison a regular file
crw-rw-rw- 1 root tty  5, 0 May 26 08:11 /dev/tty
brw-rw---- 1 root disk 8, 0 May 26 08:23 /dev/sda
# c = character -> transfer one byte at a time (keyboard, terminal)
# b = block -> transfer in blocks (chunks) (hdds, ssds, usb)
  • Hardware needs a way for programs to talk to it.
  • Unix does this by representing devices as fake files in the /dev directory.
  • When you read/write one of these files, the kernel secretly routes that request to the actual driver for that hardware.

These block and character files are basically config files to talk to a device like an API config file: host: 192.168.1.1, port: 8080

Format

Instead of file size 533 it uses those bytes in the fs to store the major, minor (ls knows to display with a comma because of the file type).

Major Minor in action:

# For /dev/sda with 8, 0:
8 = "use the SCSI/SATA disk driver"
0 = "the first disk"

# Terminal interfaces using driver "4", using virtual consoles 0-2
crw------- 1 root tty     4,  0 May 25 07:20 /dev/tty0
crw------- 1 root tty     4,  1 May 25 07:20 /dev/tty1
crw------- 1 mat  tty     4,  2 May 25 07:20 /dev/tty2

Local domain socket files

  • Same idea as char/block files - not a real file, just a rendezvous point in the filesystem
  • Instead of pointing to a hardware driver like device files, a local socket points to another process
  • You knock on the file, and instead of the kernel routing to a driver, it routes to whatever process is listening on that socket
  • Only accessible from the local host, referred to through a filesystem object rather than a network port

It lets you use your normally network-designed code but point it to a file. You get to fully bypass the TCP/IP stack - connect(), send(), recv() all work the same.

Instead of 192.168.1.1:5432 you point it to /var/run/postgresql/.s.PGSQL.5432

srw-rw---- 1 root docker 0 May 25 07:20 /run/docker.sock
  • Used heavily by docker, databases, and redis

Hard links

  • regular files are hardlinks, they’re the first link to the inode
  • point directly to the inode (the actual data on disk)
  • the filesystem just tracks a reference count - delete the “original” and the data lives on as long as at least one hard link remains

Symbolic (Soft) Links

  • store the path to the target as their content
  • is a referenced by name
  • if you delete the original the symlink breaks
  • can be relative or aboslute path

Note: use an absolute path when the symlink lives somewhere else or a relative path that makes sense from the symlink’s location, not yours.

ln original.txt hardlink.txt    # hard link
ln -s original.txt hardlink.txt # soft link

ls -li # i flag = inode
#               2 = the link count (2 because we have two hard links)
527942 -rw-rw-r-- 2 mat mat 12 May 26 19:50 hardlink.txt  # -- hardlink and original share the same inode
527942 -rw-rw-r-- 2 mat mat 12 May 26 19:50 original.txt  #  
527941 lrwxrwxrwx 1 mat mat 12 May 26 19:51 softlink.txt -> original.txt # seperate inode, l = link (similar to d for dir)

# ./hardlink.txt ./softlink.txt ./original.txt
hello world
© 2026 Monjiapawne