问题描述
UNIX/Linux系统如何在内部管理符号链接.众所周知，即使没有实际的目标文件也可能存在符号链接(悬挂链接).那么在内部代表符号链接的是什么.
How are symbolic links managed internally by UNIX/Linux systems. It is known that a symbolic link may exist even without an actual target file (Dangling link). So what is that which represents a symbolic link internally.
在Windows中，答案是reparse point.
In Windows, the answer is a reparse point.
问题:
答案是UNIX/Linux中的inode吗?
Is the answer an inode in UNIX/Linux?
如果是，那么目标和链接的索引节点号是否相同?
If yes, then will the inode number be same for target and links?
如果是，链接inode可以具有与目标inode不同的权限(如果存在)吗?
If yes, can the link inode can have permissions different from that of target's inode (if one exists)?
推荐答案
与UNIX/Linux无关，而与文件系统实现有关-但是，是的，Unix/Linux在内核级别使用inode，文件系统实现具有inode(至少是虚拟的inode). ).
It is not about UNIX/Linux but about filesystem implementation - but yes, Unix/Linux uses inodes at kernel level and filesystem implementations have inodes (at least virtual ones).
通常，符号链接只是文件(顺便说一句，目录也是文件)，具有:
In the general, symbolic links are simply files (btw, directories are also files), that have:
- "inode"中的
- flag
file-type告诉系统该文件是符号链接" - file-content:目标路径-换句话说:符号链接只是一个文件，其中包含在inode中带有标志的文件名.
- the flag
file-typein the "inode" that tells to the system this file is a "symbolic link" - file-content: path to the target - in other words: a symbolic link is simply a file which contains a filename with a flag in the inode.
虚拟文件系统也可以具有符号链接，因此，请检查FUSE或其他文件系统实现源. (ext2/ext3/ufs..etc)
Virtual filesystems can have symbolic links too, so, check FUSE or some other filesystem implementation sources. (ext2/ext3/ufs..etc)
所以
取决于文件系统的实现，但是可以，通常inode包含文件类型"(以及所有者，访问权限，时间戳，大小，数据块指针).有些文件系统没有inode(在物理实现中)，但是只有虚拟inode"来保持与内核的兼容性.
depends on filesystem implementation, but yes, generally the inode contains a "file-type" (and owners, access rights, timestamps, size, pointers to data blocks). There are filesystems that don't have inodes (in a physical implementation) but have only "virtual inodes" for maintaining compatibility with the kernel.
否.通常，符号链接是一个具有自己的inode的文件(具有文件类型，自己的数据块等)
No. Usually, the symlink is a file with its own inode, (with file-type, own data blocks, etc.)
这与 符号链接文件的处理方式有关.通常，内核不允许更改符号链接权限-符号链接始终具有默认权限.您可以编写自己的文件系统，以允许对符号链接使用不同的权限，但是您会遇到麻烦，因为chmod之类的通用程序本身不会更改符号链接的权限，因此无论如何制作这样的文件系统都是毫无意义的
This is about how symlink files are handled. Usually, the kernel doesn't allow changes to the symlink permissions - and symlinks always have default permissions. You could write your own filesystem that would allow different permissions for symlinks, but you would get into trouble because common programs like chmod don't change permissions on symlinks themselves, so making such a filesystem would be pointless anyway)
要了解硬链接和符号链接之间的区别，您应该首先了解目录.
To understand the difference between hard links and symlinks, you should understand directories first.
目录是告诉内核将此文件作为file-name到inode_number的映射来处理"的文件(在inode中以标记区分).硬链接只是映射到相同inode的文件名.因此，如果目录文件包含:
Directories are files (with differentiated by a flag in the inode) that tell the kernel, "handle this file as a map of file-name to inode_number". Hard-links are simply file names that map to the same inode. So if the directory-file contains:
file_a: 1000
file_b: 1001
file_c: 1000
上面的意思是，在此目录中，包含3个文件:
the above means, in this directory, are 3 files:
- inode 1000描述的file_a
- 由inode 1001和 描述的file_b
- file_c再次由inode 1000描述(因此，它是与 file_a的硬链接，而不是与 file_a的硬链接-因为无法确定哪个文件名排在最前面-它们相同).
- file_a described by inode 1000
- file_b described by inode 1001 and
- file_c again described by inode 1000 (so it is a hard link with file_a, not hardlink to file_a - because it is impossible to tell which filename came first - they are identical).
这是符号链接的主要区别，其中file_b的索引节点(索引节点1001)可以具有 content (内容)"file_a"和一个标志，表示这是符号链接".在这种情况下，file_b将是指向file_a的符号链接.
This is the main difference to symlinks, where the inode of file_b (inode 1001) could have content "file_a" and a flag meaning "this is a symlink". In this case, file_b would be a symlink pointing to file_a.
这篇关于符号链接后面有什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！