24

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.

Improve this question

2 Answers 2

Reset to default
35

/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.

Improve this answer
5
  • Input? What does it supply an endless list of NUL characters? Commented 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. Commented 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. Commented Apr 10, 2015 at 21:06
  • Yep, that's correct. Commented Apr 10, 2015 at 21:10
  • 3
    @JonathonWisnoski look at /dev/zero for that. Commented Apr 10, 2015 at 21:56
17

/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.

Improve this answer
10
  • 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. Commented 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. Commented 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. Commented 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. Commented 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. Commented Apr 12, 2015 at 0:15

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.