通过挂载点创建和读取OSS Symlink

相对路径 symlink 与绝对路径 symlink

symlink 的目标路径有两种形式：绝对路径与相对路径。绝对路径形式的 symlink 以文件系统根目录 / 为基准解析，与链接自身的位置无关；相对路径形式的 symlink 则以链接所在的目录为基准解析，而不是以当前工作目录为基准。“相对谁”是理解 symlink 行为的关键，也是最容易产生误解的地方。

以一个例子说明。假设挂载点为 /mnt/ossfs，Bucket 中存在文件 oss://<bucket>/a/c/target，现在要在目录 oss://<bucket>/a/b/ 下创建链接 oss://<bucket>/a/b/link 指向它：

ln -s ../c/target /mnt/ossfs/a/b/link

解析这条链接时，内核从链接所在的本地目录 /mnt/ossfs/a/b/ 出发拼接目标路径：/mnt/ossfs/a/b/ + ../c/target = /mnt/ossfs/a/c/target。这个过程与执行命令时所处的目录无关，无论在哪个工作目录下执行 cat /mnt/ossfs/a/b/link，解析结果都相同。如果误以为 ../c/target 是以工作目录为基准解析的，就会对链接的实际指向产生错误预期。

需要注意的是，readlink 返回的并不是创建时传入的原始字符串，而是规范化后的相对路径，例如上例返回 ../../a/c/target。规范化结果以挂载点根目录为基准重新表达目标位置，跟随链接时得到的对象与创建时一致。

OSS Symlink 对象与控制台兼容

OSS 原生支持 Symlink 对象：通过 PutSymlink 接口创建，目标记录在 x-oss-symlink-target 头中，通过 GetSymlink 接口读取。需要注意的是，PutSymlink 接口本身并不校验目标内容，理论上可以写入任意字符串；“目标必须是 Bucket 内对象名”实际上是 OSS 控制台的解析约定。控制台展示和跳转 Symlink 对象时，会把目标当作 Bucket 内的对象名来解析；若目标被写成其他形式（例如绝对路径），控制台将无法识别和跳转，成为死链接。

也就是说，控制台约定的解析基准是 Bucket 根目录，与 POSIX 相对路径 symlink“以链接所在目录为基准”不同。仍以上文的例子说明，同一条链接 a/b/link 指向 a/c/target，在不同视角下的目标字符串并不相同：

ossfs 2.0 的 symlink 实现遵循这一约定，并在两套解析基准之间自动完成转换：在挂载点内创建的链接，OSS 存储的 target 为 Bucket 内相对路径（如 a/c/target），控制台可正常识别和跳转；通过 API 或控制台创建、target 为 Bucket 内相对路径的 Symlink 对象，在挂载点内也能正常 readlink 和读取。若 target 写成以 / 开头的绝对路径，挂载点读取该链接会返回 EINVAL。

命令行方式

以挂载点 /mnt/ossfs、在 /mnt/ossfs/a/b/ 下创建指向 /mnt/ossfs/a/c/target 的链接为例，目标需使用相对路径：

cd /mnt/ossfs/a/b
ln -s ../c/target link

# 或者跳过 cd 直接使用
ln -s ../c/target /mnt/ossfs/a/b/link

# 读取链接指向，返回规范化后的相对路径（../../a/c/target）
readlink /mnt/ossfs/a/b/link

# 跟随链接正常读取目标内容
cat /mnt/ossfs/a/b/link

Python 脚本方式

批量创建链接时，可先将目标规范化为“相对于链接所在目录”的相对路径。与 ossfs 2.0 运行时无法判定绝对路径归属不同，脚本由使用者显式传入挂载点，因此可以直接接受本地绝对路径，并在工具侧完成换算：

#!/usr/bin/env python3
"""Create relative symlinks on an ossfs 2.0 mountpoint.

Usage: python3 create_oss_symlink.py <mountpoint> <link_path> <target_path>
All arguments are local paths; <link_path> and <target_path> must be under
<mountpoint>. The script converts the target into a path relative to the
link's parent directory, so that ossfs 2.0 stores it as an in-bucket object
name.
"""
import os
import sys


def create_relative_symlink(mountpoint, link_path, target_path):
    mountpoint = os.path.realpath(mountpoint)

    def to_bucket_rel(p):
        # Lexical conversion, consistent with ossfs 2.0: no symlink
        # expansion, inner ".." folded literally.
        p = os.path.normpath(os.path.abspath(p))
        if not p.startswith(mountpoint + os.sep):
            raise ValueError(f"path escapes the mountpoint: {p}")
        return os.path.relpath(p, mountpoint)

    # Bucket-relative object name of the target (what OSS actually stores).
    bucket_target = to_bucket_rel(target_path)
    link_path = os.path.abspath(link_path)
    if not link_path.startswith(mountpoint + os.sep):
        raise ValueError(f"link path escapes the mountpoint: {link_path}")

    # POSIX readlink semantics: relative to the link's parent directory.
    link_parent_rel = os.path.relpath(os.path.dirname(link_path), mountpoint)
    relative_target = os.path.relpath(bucket_target, link_parent_rel)

    if os.path.lexists(link_path):
        os.remove(link_path)
    os.symlink(relative_target, link_path)
    print(f"{link_path} -> {relative_target}")


if __name__ == "__main__":
    if len(sys.argv) != 4:
        print(__doc__)
        sys.exit(1)
    create_relative_symlink(sys.argv[1], sys.argv[2], sys.argv[3])

使用示例：

python3 create_oss_symlink.py /mnt/ossfs /mnt/ossfs/a/b/link /mnt/ossfs/a/c/target

脚本以挂载点根为基准换算目标。若挂载时配置了 oss_bucket_prefix，OSS 实际存储的对象名为该前缀拼接脚本内部的 bucket 相对路径，换算由 ossfs 2.0 自动完成，不影响脚本的使用方式。