什么原因导致 ENOENT 错误?

什么原因导致 ENOENT 错误?

我正在运行 Node 脚本并在此路径上收到此错误:

 ENOENT ../../../Library/Application Support/Google/Chrome/RunningChromeVersion

我可以通过关闭 Chrome 来消除错误。

我通过谷歌搜索得到的大多数信息都告诉我埃诺恩特错误是由不存在的文件/文件夹引起的。

但在这种情况下,该文件夹显然存在,并且与 Chrome 正在运行有关。

我希望能够遍历正在使用的文件。这可能吗?

大多数其他错误都是由 Apple 引起的,而我使用的是 Apple 机器。

ENOENT ../../../Library/Containers/com.apple..NowPlayingWidgetContainer/Data/Documents/iChats

答案1

所命名的项目RunningChromeVersion存在,但它是符号链接谁的目标不存在。您的 Node 脚本没有对链接进行任何特殊处理,因此尝试打开链接时的默认操作是跟随链接。

链接的目标不存在,因为它本来就不是指向文件的。它是一个虚拟链接,在“目标”字段中存储了一些不相关的信息(例如版本号),而文件名通常存储在该字段中。

例如,以下是 Linux 上的等效内容(请注意l“类型”指示):

$ ls -l ~/.config/chromium
总计 4.2M
...
drwx------ 3 grawity 用户 4.0K 5月14日 09:52 ShaderCache/
rwxrwxrwx 1 grawity 用户 20 五月 17 13:38 SingletonCookie-> 18396286875963223082
rwxrwxrwx 1 grawity 用户 12 五月 17 13:38 SingletonLock-> 霜冻-453916
rwxrwxrwx 1 grawity 用户 50 五月 17 13:38 SingletonSocket-> /tmp/.org.chromium.Chromium.7Og2ow/SingletonSocket=
drwx------ 3 grawity 用户 4.0K 12月27日 08:02 SSLErrorAssistant/
...

这是创建“锁文件”的一种常见方法;只需要一个系统调用就可以原子地创建一个链接(如果已经存在则会失败),一个系统调用就可以读取其“内容”(“目标”字段),我认为它甚至与 NFS/SMB/AFS 兼容,而实际的文件锁在这些网络文件系统中往往不太好用。

如果你使用 readdir() 来扫描目录,那么每个目录条目已经包含有关其类型的信息:例如在 Node 中,你可以调用.isSymbolicLink()在每个 readdir 结果上。

如果你只有路径,你可以使用 Node 等效的lstat()函数来检查路径是否是符号链接并避免以这种方式遍历它(readlink()如果愿意,还可以读取其“目标”字段)。

事实上受到推崇的在进行递归文件搜索时跳过符号链接,因为跟随符号链接可能会导致您陷入无限循环(例如,dirA/linkB 指向 .. /dirB,但 dirB/linkA 指向 .. /dirA,现在您陷入困境)。

相关内容