前一篇文章，设计了用于fuse的数据结构。
https://linuxdev.cc/article/a0iby1.html
struct inode {
struct hlist_node hash;
unsigned refcnt;
uint64_t ino;
struct dentry *dentry;
};
struct dentry {
struct hlist_node hash;
unsigned refcnt;
char *name;
struct dentry *parent;
struct inode *inode;
struct dentry *next;
};
本篇讨论，如何实现fuse文件系统，将后备文件系统的软链接，转为硬链接。
处理流程如下：
1 通过父目录的inode id，得到父目录的inode和dentry，计算出父目录的路径。
2 通过父目录的路径+子文件名字。得到子文件的路径。
3 对子文件进行stat()统计，获得子文件的属性。
4 如果子文件是一个符号链接，则使用readlink()读取链接的内容。
5 解析符号链接，定位到目标文件。
6 添加目标文件的inode和dentry（如果已经添加，就不需要重复添加）
上面这个流程，应该是自然而然，没有争议的。接下来要讨论的有3个点：
第一个讨论点：
返回目标文件自身的inode id，还是单独维护一套新的inode id？
返回新的inode id，在用户层面，看到的是两个不同的目录树。需要独立维护，比如左边删除了一个文件，右边需要同步，这肯定需要额外的数据结构，变得非常复杂。而返回目标文件本身的inode id。在用户看来就是真正的硬链接。因此这里选择：返回目标文件自身的inode id。
第二个讨论点：
是否需要为符号链接本身创建dentry？
之前想的是创建dentry，然后和目标文件的dentry关联起来，比如目标文件被删除，那么这个符号链接的dentry也同步删除，这需要额外的数据结构来维护。但是创建dentry也是有好处的，比如delete的时候，不用遍历所有源，可以直接删除。move的时候，也可以更好的来检测是否有冲突。
如果不创建dentry，那么逻辑就相当简单了。对目标文件进行rename或者删除，符号链接需要做任何事情。缺点是delete符号链接的时候，没有dentry，需要再次扫描一下。
两个方案对比：不创建dentry更好。
第三个讨论点：
如何返回属性，比如文件权限，返回符号链接的，还是目标文件的？
直接返回目标文件的比较好，因为对于目录，子文件的权限又没法按符号链接的返回，而且返回符号链接的会导致同一个inode，从不同目录访问的时候，返回的属性不一样，存在不一致的问题。
上面3个讨论确定后，最后一步：
7 返回目标文件的inode id和属性