📄pnpm软硬链接
type
status
date
slug
summary
tags
category
icon
password
Status
硬软链接
文件夹中的文件实际上是一个指针，但这个指针并不是直接指向我们在磁盘中存储文件的位置，而是指向一个 inode 块，inode 中存储着文件在磁盘中的各种信息。我们把这类链接成为硬链接。
但是还有一种链接，它存储的并不是实际的值，而是另一个硬链接的地址，我们把这类链接成为软链接。
硬链接（
ln 源文件 软链接文件）- 指向相同inode的多个文件互为硬链接文件；
- 删除任意一个硬链接，文件实体不会被删除；
- 删除了所有硬链接文件，文件实体才会被删除；
- 可以通过设置硬链接来防止重要文件被误删；
- 对于静态文件（没有进程正在调用），当硬链接数为0时文件就被删除。如果有进程正在调用，则无法删除或者即使文件名被删除但空间不会释放。
- 硬链接是
regular file，和正常文件一样；
软链接（
ln -s 源文件 软链接文件）- 软链接类似快捷方式，存放的是源文件的路径，指向源文件；
- 删除源文件，软链接依然存在，但访问报错，找不到源文件了；
- 软链接和源文件是不同的文件，文件类型不同，inode号也不同；
- 软链接是
symbolic link；
pnpm 为什么要使用软链接和硬链接
在 pnpm 之前，npm 和 yarn 为了提高包的复用率，都采用了扁平化的装包策略。扁平化的安装方式会导致我们的 node_modules 文件夹和 package.json 存在很大的出入。由于 node 的寻找包的规则，这些包都是可以在项目中直接被引用的，也就是说我们在项目中引用了未在 package.json 中声明的包，这显然是不安全的，这种情况称为幽灵依赖。
pnpm 的软链接就是将 node_modules 里的文件软链接到对应的
.pnpm/[package_name]@version/node_modules/[package_name] 中。pnpm 通过软链接，既保证了不会出现幽灵依赖的问题，同时也能兼容 node 的寻找模块方式。
pnpm 的硬链接
所有 npm 包都安装在全局目录
~/.pnpm-store/v3/files 下，同一版本的包仅存储一份内容，甚至不同版本的包也仅存储 diff 内容pnpm 通过硬链接的方式保证了相同的包不会被重复下载，比如说我们已经在 repoA 中下载过一次 express@4.17.1 版本，那我们后续在 repoB 中安装 express@4.17.1 的时候是会被复用的，具体就是 repoA 中的 express 中的文件和 repoB 中的 express 中的文件指向的是同一个 inode。
每个项目的
node_modules 下有 .pnpm 目录以打平结构管理每个版本包的源码内容，以硬链接方式指向 pnpm-store 中的文件地址。所以每个包的寻找都要经过三层结构：
node_modules/package-a > 软链接 node_modules/.pnpm/package-a@1.0.0/node_modules/package-a > 硬链接 ~/.pnpm-store/v3/files/00/xxxxxx。pnpm 中的问题
pnpm 的出现对于 npm 和 yarn 来说是一个比较彻底的改变，解决了很多 npm 安装依赖存在的问题，node_modules 过大、幽灵依赖。pnpm 目前存在的限制在于它修改了文件的相对位置，将包和其依赖放在同一个 node_modules 下，这让一些使用了绝对路径和幽灵依赖的包在使用 pnpm 安装时会存在问题，不过 pnpm 也在解决这个问题，即通过软链接的形式将所有非工程直接依赖的包放在 .pnpm/node_modules 下，这样就解决了找不到包的问题，项目在迁移 pnpm 的话可能会发现 pnpm i 后启动项目还有未安装的包，这个时候就要考虑是否引用了幽灵依赖。
inode查看命令
- stat：列出文件大小，文件所占的块数，块的大小，主设备号和次设备号，inode number，链接数，访问权限，uid,gid,atime,mtime,ctime。
- df -i：查看硬盘的inode总数和使用的个数。列出文件系统，总块数，已用块数，可用块数，已用所占比例，挂载点。
- ls -li：查看目录下各文件的inode号。
- Twikoo