What does the 'c' mean in a directory listing?

[carlarogers]

I tried looking this up but was getting nowhere. A brief answer would be appreciated immensely. Thank you

 

[osprey]

The c means the file is a character device. The d in the pic in post #1 means it's a directory. A disk in the machine, on the other hand is a block device which uses a b:

$ ll /dev/nvme0n1
brw-rw---- 1 root disk 259, 0 Sep 15 08:34 /dev/nvme0n1

The character device is so called because it can have streams of characters sent to it and received from it. That's it in brief.

 

[carlarogers]

I am somewhat acquainted with the d in that position. I have noticed a few - in that position. C is new to me.

I am going to lookup character device

 

[carlarogers]

 

[osprey]

Here are some observations about the data provided in posts #3 and #4.

The files have a group ownership of www-data.
The group ID www-data is normally associated with the apache2 web server where it's the default group ownership.

Since apache is not used here I can't say more.

In relation to the "1, 3" in the line:

crwxrwxr-x 1 dan www-data 1, 3 2024-03-16 01:45:49 access.log

the numbers refer to device numbers which are used in the kernel. In this case the number 1 is the major device number, and 3 is the minor device number. The number 1 is set as a character device in the kernel, and the number 3 refers to the particular device: /dev/null, as shown here.

$ ls -al /dev/null
crw-rw-rw- 1 root root 1, 3 Sep 15 08:34 /dev/null

The list of devices with their major and minor numbers are shown in the kernel docs here:

Linux allocated devices (4.x+ version) — The Linux Kernel documentation

The /dev/null character device is commonly referred to as "the bit bucket" which means that any characters sent there are discarded, never to be retrieved.

The relationship between /dev/null and the file names "access.log" and "error.log" is not one that makes sense in the output provided in the above posts. There appears to be some corruption in the system for several reasons one may speculate about:

1. access.log and error.log are ordinary files and the normal output of the ls command does not provide device numbers for ordinary files. It does so for device files in the directory /dev as shown above in the case of /dev/null. Further, ordinary files have the dash character at the beginning of the line: -rw-rw-rw-..... and not the c character which is reserved for character devices.

2. The filesystem may actually be corrupted so that when ls is reading files, the inodes with the correct information about the files are somehow unable to provide it correctly.

3. The ls executable itself may be corrupted.

In other words, the output in the data provided is abnormal with no obvious explanation.

Finally, in relation to the file size which is shown in the ls output, it can be shown in a more human readable form than a long string of numbers by using the -h option, for example:

$ ls -al abs-guide2014.pdf
-rw-r--r-- 1 tom tom 2741648 Nov 21  2023 abs-guide2014.pdf

$ ls -alh abs-guide2014.pdf
-rw-r--r-- 1 tom tom 2.7M Nov 21  2023 abs-guide2014.pdf

The size of 2.7 megabytes is usually easier to read than the the number shown in bytes.

 

[CaffeineAddict]

I am going to lookup character device

Here is additional info read more about device files:

Device file - Wikipedia

en.wikipedia.org

There are terminal commands to manage device files:

• mknod is used to create a new device file.
• tty is used to get device file of the current terminal

Device files are located in /dev directory.

 

[carlarogers]

Here are some observations about the data provided in posts #3 and #4.

The files have a group ownership of www-data.
The group ID www-data is normally associated with the apache2 web server where it's the default group ownership.

Since apache is not used here I can't say more.

In relation to the "1, 3" in the line:

crwxrwxr-x 1 dan www-data 1, 3 2024-03-16 01:45:49 access.log

the numbers refer to device numbers which are used in the kernel. In this case the number 1 is the major device number, and 3 is the minor device number. The number 1 is set as a character device in the kernel, and the number 3 refers to the particular device: /dev/null, as shown here.

$ ls -al /dev/null
crw-rw-rw- 1 root root 1, 3 Sep 15 08:34 /dev/null

The list of devices with their major and minor numbers are shown in the kernel docs here:

Linux allocated devices (4.x+ version) — The Linux Kernel documentation

The /dev/null character device is commonly referred to as "the bit bucket" which means that any characters sent there are discarded, never to be retrieved.

The relationship between /dev/null and the file names "access.log" and "error.log" is not one that makes sense in the output provided in the above posts. There appears to be some corruption in the system for several reasons one may speculate about:

1. access.log and error.log are ordinary files and the normal output of the ls command does not provide device numbers for ordinary files. It does so for device files in the directory /dev as shown above in the case of /dev/null. Further, ordinary files have the dash character at the beginning of the line: -rw-rw-rw-..... and not the c character which is reserved for character devices.

2. The filesystem may actually be corrupted so that when ls is reading files, the inodes with the correct information about the files are somehow unable to provide it correctly.

3. The ls executable itself may be corrupted.

In other words, the output in the data provided is abnormal with no obvious explanation.

Finally, in relation to the file size which is shown in the ls output, it can be shown in a more human readable form than a long string of numbers by using the -h option, for example:

$ ls -al abs-guide2014.pdf
-rw-r--r-- 1 tom tom 2741648 Nov 21  2023 abs-guide2014.pdf

$ ls -alh abs-guide2014.pdf
-rw-r--r-- 1 tom tom 2.7M Nov 21  2023 abs-guide2014.pdf

The size of 2.7 megabytes is usually easier to read than the the number shown in bytes.

.
.
.
This is fantastic in the detail and analysis, I appreciate this immensely.

The c in the first position and the 1, 3 in the size column both showed up after I had run a command which I thought would empty the file. Basically, these files were large and I wanted them reset blank. The command I used was:

cp /dev/null access.log

The result I expected was the size would be shown as 0 and nothing else would change.

TWO EXPLANATIONS
1. I have emptied files many times using dev/null, but I did it wrong this time. I always have to look up to find a command for emptying a file, because I never remember the exact command. I never have known exactly what dev/null is, I just remember it was part of commands for emptying a file. In this case, I googled something like "linux empty large file" and clicked through to an answer with 374 upvotes that says

cp /dev/null filename works.

Link to "answer" stating cp /dev/null will empty a file

Now that I know a little more about what /dev/null is, I can't see how that command could ever have worked. Looks like that answer needs correction.

2. Seems obvious now, cp /dev/null filename puts a copy of /dev/null where filename was, making the file listing I posted explainable. The command I should have run was

cat /dev/null access.log

 

[osprey]

Thanks for the explanation of how things came about.

On emptying files, I did read the link, but here it is done differently by using cat. In the example below after running the cat command, enter cntl+d, which is the "end of file" command (see the output of: stty -a).

When the cat command is run below, it will open the prompt for further entries, but since the aim is to have an empty file, one presses the cntl+d keys to end the file leaving it empty. The result is shown in the example where the file is initially 452 bytes, and after the processing is zero bytes.

$ ll
<snip>
-rw-rw-r-- 1 tom tom  452 Sep 10 11:56 file
<snip>

$ cat > file

$ ll
<snip>
-rw-rw-r-- 1 tom tom    0 Sep 16 06:46 file

There is the extra keystroke of cntl+d to run compared to other methods, but the advantage of using cat is that it writes over the file on the disk where it's at and doesn't create another file of the same name and doesn't have to bother with extra processing of sending data to /dev/null, so in that respect, one might consider using /dev/null for this as overkill.