I have just found out that /dev/null is a file and not a directory.

I'm just wondering if it has an actual file size.

2 Answers 2


/dev/null is not really a file. It's a character device!

$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Apr 10 09:53 /dev/null

The first letter c of the permissions string (crw-rw-rw-) indicates this. For regular files, it would be a - instead.

So in easy words: /dev/null is not a file but a virtual device mapped to this path in the file system, which has the only purpose to swallow and vanish data - like a black hole.
It can also be used as input though, then it acts like an empty file (size 0) and immediately returns an EOF (End Of File).

Therefore you can not really say that /dev/null has a specific file size, as it's not a regular file on any storage medium.

  • Input? What does it supply an endless list of NUL characters?
    – Jonathon
    Apr 10, 2015 at 20:52
  • @JonathonWisnoski I don't know exactly and I never used it like this, so I can just give you this link to a question on StackOverflow where it's explained.
    – Byte Commander
    Apr 10, 2015 at 21:04
  • 7
    @JonathonWisnoski, no - it behaves like a zero-sized file on input, so that the first read from it reports that the file is at EOF.
    – godlygeek
    Apr 10, 2015 at 21:06
  • Yep, that's correct.
    – godlygeek
    Apr 10, 2015 at 21:10
  • 3
    @JonathonWisnoski look at /dev/zero for that. Apr 10, 2015 at 21:56

/dev/null is a special kind of file called "device file".

Device files act as a interface to some kernel functions. They just occupy the space that is needed for a directory entry ("inode") but don't have any real content and don't have an actual file size.

Other device files are e.g. /dev/sda (generally a HDD or SSD), /dev/zero (a file that generates zero's when read), or /dev/random (a file that generates random data when read). Actually about all files in /dev/ are either device files or links pointing to device files.

  • While I find most of this answer correct (+1), I think that it's a little misleading to say that they occupy the size of an inode entry. They either don't occupy any space, if referring to disk space, or they take more, if referring to their whole implementation as character devices.
    – kos
    Apr 10, 2015 at 18:33
  • 2
    Just like any other file a device file needs an inode that stores the owner, permissions, major/minor number and other metadata. It depends on the file system how and where this inodes are stored (you can use mknod to create device files anywhere you want). For virtual file systems like /dev/ the inode doesn't occupy disc space but some memory. Apr 10, 2015 at 19:00
  • Exactly. I think I didn't express myself well, so let me rephrase. Perhaps what I'm pointing out it's a little picky, so forgive me for that. What I meant is that if you state that each character device occupies some space in memory due to its inode entry, perhaps you want to point out that functions to be called upon read/write on such device, which are loaded along with them, do so also.
    – kos
    Apr 10, 2015 at 19:12
  • Is it really correct to say a file occupies the space occupied by its inode table entry? I don't think this is usually included in what people--and software people have written--mean when they talk about file size. In particular, asking ls and du to report the size of a character special device like /dev/null or /dev/random yields 0. Apr 11, 2015 at 0:09
  • Sorry, but I downvoted this answer, because unless someone prove me wrong on what I've said (which I might be), I still think that it's not correct to state that a character device occupies the space of an inode entry.
    – kos
    Apr 12, 2015 at 0:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.