File permissions can generally be considered as 0 123 456 789, a total of ten digits:
0: Indicates the file type of the file. In Windows, a file association technology is used to associate the corresponding application through the extension, so that double-clicking a file can achieve the purpose of calling the corresponding application to open it, which is simple and fast. However, for users, the advantage is convenience, and the disadvantage is that it hides a substantial thing: the real type of the file is actually irrelevant to its extension.
For example: a pure text file, I can name it "my singing voice.mp3", and then double-click under win, it will call the corresponding music player to open, the result is obvious, it must be wrong. In turn, I can also name a real MP3 file "Roster.txt", double-click it under win, and usually call the corresponding text editor to open it, but I said you also know that the display must be garbled .
The above two examples are to illustrate the point that the true type of a file has nothing to do with its extension.
So how do you know the type of file without knowing the file extension? This is the case in Linux.
There are only the following file types in Linux:
1.-, ordinary files.
2.d, directory file, d is short for directory.
3.l, soft link file, also known as symbolic link file, s is short for soft or symbolic.
4. b, block file, is a kind of device file (there is another kind), b is short for block.
5.c, a character file, is also a type of device file (this is the second type), and c is a character file.
The most primitive Linux systems are only these five, so the 0th place can only be one of the above five.
Then you will have questions,
1. What kind of MP3 file is it? Answer: ordinary files.
2. What kind of binary file is it? Answer: ordinary files.
3. What kind of text file is it? Answer: ordinary files.
4. Why is there no type representation for hard links? Answer: Although there is only one word difference between the hard link and the soft link, the essence is completely different. The hard link is also a file. Its type is ordinary file.
Why does the above say so much? The purpose is to pave the way for the knowledge below.
Well, 123-456-789 is easy to say. Anyone who knows this area knows that they are just the difference between the user-belonging group-the other three groups. We can use any one of them as an example to explain rwx.
r：read，w：write，x：execute。
How should we remember the difference between the two? ? Is it rote memorization? NO.
We should know why and why. Below I try to start from the nature of the query file and content to explain why rwx permissions have different meanings for the two!
To understand what is said below, knowledge of the Linux file system is needed to pave the way. If you don't know the concept of inode, you will basically suffer.
Again, the content of the file has nothing to do with the file name used at the time; the type of the file has nothing to do with the file name at the time.
Viewing the contents of a file is actually a process like this:
For example, you used this command: cat /tmp/abc.txt
1. You only passed an absolute path, /tmp/abc.txt. The system first needs to know the inode of the /tmp/abc.txt file. How to know?
2. Remember a rule, the parent directory of a file will (record) know the inode number of the file! (At this moment, I wonder if you have realized something, don’t worry, then look down)
3. Then I get the file name "/tmp/abc.txt", I have to know the situation of the /tmp directory first, and to know the situation of the /tmp directory, I have to know the situation of the / directory first, so I can start from / The directory starts (assuming that the inode number of the / directory is 0, and this is hard-coded), and then go to a table called inode-table to find the data field pointed to by the inode number 0, and then you can find some from the data field Similar to the following: (It looks like a table, doesn't it? In fact, you can imagine that the directory file is a table that stores the file names inside it and the inode number corresponding to the file name)
File name inode number
bin 18
var 19
tmp 20
… …
Well, we found the inode number corresponding to the file name "/tmp" from the "/", this directory file, which is 20. (Assuming)
4. Then we use the inode number 20 to find the data field corresponding to 20 in the inode-table, and then from the data field, we will find a table: (Why is it a table again? Because "/" is a directory, "/Tmp" is also a directory, so of course the data field is still a table)
File name inode number
abc.txt 8899
bbb.mp3 10088
kkk.jpg 20000
… …
Well, we found the inode number of /tmp/abc.txt, which is 8899. According to the above rule, do we have to find the data field corresponding to No. 8899 in the inode-table again? Right, that is it.
5. We find the data field corresponding to the inode number 8899, so we will find the following contents:
"Abcdefg" (assuming that the content of the file is like this)
…
There are questions again, because Mao is not a watch this time?
Answer: The /tmp/abc.txt file is no longer a directory file. It is an ordinary file, and it usually stores some strings.
Reflected in essence:
Ordinary file: store ordinary data, usually a string.
Directory file: A table is stored, which is the mapping relationship between all file names and inodes under the directory file.
Obtain the inode number of this file from the parent directory---->Find the starting point and other information in the data field corresponding to the inode number in the inode-table table---->Go to this data field to read the file Content (the content of a common file is generally a string, and the content of a directory file is a table)
If you really understand what I said above, then it becomes much easier.
The key is to access any file. It depends on whether you can get the inode number. It’s easy to get the inode, just take the inode number to search in the inode table, and finally find the data field, then you can find the content of the file
Then the whole process is not only related to the permissions of this file, but also related to the permissions of its parent directory (and the parent directory of the parent directory...) (whether you can get the inode of this file)
Reflected in the order: (In other words, this is the most practical appearance)
======
For ordinary files, the meaning of rwx is:
r: You can get the name and content of this ordinary file.
w: You can modify the content and file name of this file. The file can be deleted, but the user will get a prompt whether to delete the write-protected file.
x: Whether the file has the permission to be executed.
======
For catalog files, the meaning of rwx is:
rx: You can enter the cd directory to get the storage status in the directory, but you cannot modify the name of the file (directory) stored in the directory, nor can you create new files and directories in the directory
-wx: You can enter the cd directory, but you can't see the storage in the directory (ls is not available), you can add, modify, and delete files in the directory. The content of the file or directory in this directory can be read by cat. Since the files stored in this directory are not available, the content of the file can only be obtained by guessing, cat + file name without knowing it, so this is still the case Not confidential.
-X: You can enter the cd directory, you can't see the storage situation, and you can't add, modify, or delete files in the directory. But you can still get the contents of the files in this directory through cat + xx (guess).
rw-: Can not enter the cd directory, only the file name and directory name can be obtained with ls, because the inode number of these files cannot be obtained, and of course the contents of the files in the directory cannot be obtained. You cannot add, modify, or delete files in this directory.
======
Finally, let’s summarize:
1. Although the directory file is a file (well, the core concept of Linux is Everything is file), but the storage content is just a table, about the mapping relationship between the file name and the inode number.
2. There is no dime relationship between file extension and file type.
3. There is no dime relationship between the file name of the file and the actual storage content of the file.
4. To know the process of how to find the contents of a file.
5. Why is it faster to move files from the same file system than across file systems?
Answer: Because you only need to modify the corresponding relationship between the path and the inode in a certain directory, you don't need to rewrite the data field.
6. What is a 500G hard drive that I bought, it is always less than 500G after formatting?
Answer: As you can see from this article, inode-table also takes up storage space, so inode-table takes up a lot of the missing part.