iOS中的硬链接

背景

一些文件操作场景，为了增加可靠性，通常会copy一份到个人文件夹，然后再进行文件操作。

示例场景：

1. 批量上传资源过程，通常放在一个队列中进行，为了避免上层突然清理/删除资源，导致上传资源失败，通常会copy一份资源到个人目录。
2. 阿里云OSS上传接口，要求有文件后缀，否则无法上传。SDWebImage缓存的无后缀图片，需copy到带后缀的路径B，然后通过路径B发起上传。

copy文件带来了什么负担？

1. 磁盘占用
2. io耗时
3. 后续清理文件io耗时

硬链接

通过文件硬链接，可以完美的解决以上问题。

1. 磁盘占用：多个文件对应一个实体，只占用一份存储空间。
2. io耗时：未真实拷贝，仅计数+1，瞬间操作。
3. 后续清理文件io耗时：也是计数-1，瞬时操作。

硬链接与iOS中的引用计数非常像：

• 文件原始NSFileReferenceCount为1。
• 每对文件添加一个硬链接，引用计数+1。
• 每删除一次，引用计数-1。
• 引用计数为0时，执行文件真实删除io操作。

// 创建硬链接
[[NSFileManager defaultManager] linkItemAtPath:originPath toPath:newPath error:&error];

// 删除文件
[[NSFileManager defaultManager] removeItemAtPath:path error:&error];

// 查看文件信息
[[NSFileManager defaultManager] attributesOfItemAtPath:path error:&error];

Attribute示例

常规文件

使用场景

硬链接link并不是可替换代copy操作，在对应场景下，才适合硬链接上场。

1. 此文件在目标任务过程中，不发生编辑。否则，一改全改，可能发生上传文件非预期的情况。
2. 必须为同一文件系统。
3. 文件夹无法创建硬链接。

其它

硬链接对应软链接，即windows下的快捷方式，可自行对比差异与使用场景。