FUSE用户态文件系统执行ln -fs覆盖软链接时symlink收到随机文件名问题

问题原因 #

这个现象是GNU ln命令的实现逻辑和你的FUSE文件系统实现缺失共同导致的：

1. 带-f参数的ln -s命令为了避免覆盖软链接时的竞态条件，不会直接删除原有目标文件再创建新软链接，而是采用原子替换逻辑：先在目标所在目录下创建一个随机名称的临时软链接，再通过rename系统调用将临时文件重命名为目标文件名，直接覆盖原有文件。
2. 从你提供的调试日志可以看到，你当前的symlink回调仅做了日志打印，没有实际将新创建的临时软链接的元数据存入你的文件系统的存储层，导致后续内核发起对该临时文件的GETATTR请求时，你的文件系统返回了-2 (No such file or directory)错误，ln命令判定临时软链接创建失败，直接终止了后续流程，所以你看不到后续的rename回调触发。

解决方法 #

按以下顺序修正你的FUSE实现即可：

• 补全symlink回调逻辑：收到symlink请求时，将传入的路径（临时随机文件名）、软链接指向的目标路径、对应元数据（uid、gid、创建时间等）存入你的文件系统的元数据管理模块，确保后续对该路径的getattr、readlink请求可以正常返回结果。
• 确保rename回调正常实现：当symlink执行成功后，ln会发起rename请求，将临时软链接路径重命名为目标路径（比如你的场景里的/dir/link_a），你需要在rename回调中完成元数据更新：删除原有目标路径的条目，将临时软链接的路径修改为目标路径，完成原子覆盖。
• 修正软链接的getattr逻辑：不要固定将软链接的st_size设为1024，应该设置为该软链接指向的路径字符串的实际长度，避免上层工具读取软链接内容时出现截断或冗余空字符问题。

内容的提问来源于stack exchange，提问作者Alvaro