2

A character device file is a special linux file where you can read from and write to an infinite number of chars and other file operations that you can define inside a kernel device driver.
But does this file actually exist? If we look at it as normal text file is it possible to read the contents that are inside? Like major, minor numbers?

Something similar we have with soft links. On linux machine the link is actually a path in system, but after committing it to git for example we see only "normal" text file with one string, a path to source directory.

Improve this question
1
  • You can stat such a file. It contains nothing: it is a placeholder for a connection to an appropriate device driver. Sending a /dev to git has no purpose, because the device itself is not available there. Commented Jan 23, 2023 at 11:59

1 Answer 1

Reset to default
3

But does this file actually exist?

You'll find that there is an entry in your filesystem that contains the information that this specific entry describes a device. It's not a regular file, it's still an entry in the file system.

If we look at it as normal text file

Who is "we" and what is "look at it as a normal text file"?

You can open a character device filesystem entry just like a regular file, you can read from it, you can write to it, but you cannot seek within it.

So, yes, anything that reads a file from the beginning forward can open and the character device – but it will quite possibly never finish reading it, because a character device has no marker for "this is the end" (unless something physically ends the character device).

the contents that are inside? Like major, minor numbers?

No, the major and minor device numbers are properties of the device file, not contents. What you read from the device file would be the actual data that the character device produces.

On linux machine the link is actually a path in system, but after committing it to git for example we see only "normal" text file with one string, a path to source directory.

nah, that's a layer above, that's how git handles these things. And even git lugs around the info that "this is not a regular file; on a system that supports symbolic links, represent it as such". On a symbolic link, again, the path pointed to is a property of the symbolic link, and if you open the symbolic link and read from it, you get the contents of what is being linked to. So, make a mental difference between properties and contents, and you'll be fine.

Improve this answer
3
  • thats cool, I didn't realised that there is a distinction between properties and contents. As I now understand standard file operations like open, close etc. are acting on "content". But which system is acting on properties? Kernel? User-space? Which properties are available? Where to find "list" of this properties? The obvious are the permissions, but is there more? How to display this props besides ls -la ? Commented Jan 23, 2023 at 15:31
  • The file system is something the kernel offers to the user space. So, not quite sure how to answer which is "acting" on it – both are. You know a lot of properties already – size, for regular files, for example; target path for symbolic links; owner, group, permissions for all types; major and minor numbers for device files; modification, access and creation dates; there's extended attributes, which you might rarely personally encounter, but which are used to store things on the file like whether, for example, a web server program is allowed to read a SSH configuration directory. Commented Jan 23, 2023 at 18:56
  • how you access these depends on the thing you're querying; man fstat will show you how it's done from the C programming language for size and so on. Commented Jan 23, 2023 at 18:57

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.