What causes ENOENT errors?

I am running a Node script and am getting this error at this path:

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

I can remove the error by closing Chrome.

Most of my Googling has told me that ENOENT errors are caused by files/folders that do not exit.

However, in this case the folder clearly exists and has to do with the fact that Chrome is running.

I want to be able to traverse the files even if they are in use. Is this possible?

Most of the other errors are caused by Apple and I am on an Apple machine.

ENOENT ../../../Library/Containers/

1 Answer

The item named RunningChromeVersion exists, but it is a symbolic link whose target does not exist. Your Node script doesn't give any special treatment to links, so the default action when trying to open them is to follow the link.

The link's target does not exist because it is not intended to point to a file in the first place. It's a dummy link with some unrelated information (e.g. a version number) stored in the 'target' field where a filename would normally go.

For example, here's the equivalent on Linux (note the l "type" indication):

$ ls -l ~/.config/chromium
total 4.2M
...
drwx------ 3 grawity users 4.0K May 14 09:52 ShaderCache/lrwxrwxrwx 1 grawity users 20 May 17 13:38 SingletonCookie -> 18396286875963223082lrwxrwxrwx 1 grawity users 12 May 17 13:38 SingletonLock -> frost-453916lrwxrwxrwx 1 grawity users 50 May 17 13:38 SingletonSocket -> /tmp/.org.chromium.Chromium.7Og2ow/SingletonSocket=drwx------ 3 grawity users 4.0K Dec 27 08:02 SSLErrorAssistant/
...

This is a somewhat common method of creating "lock files"; it only takes one syscall to atomically create a link (and fail if it already exists), one syscall to read its "contents" (the 'target' field), and I think it's even NFS/SMB/AFS-compatible whereas actual file locks tend to work less well with these network filesystems.

If you use readdir() to scan directories, then each directory entry already has information about its type: e.g. in Node, you can call .isSymbolicLink() on each readdir result.

If you have only the path, you can use the Node equivalent of the lstat() function to check whether a path is a symlink and avoid traversing it that way (there's also readlink() to read its 'target' field if you want to).

It is actually recommended to skip symlinks when doing recursive file search, because following symlinks might lead you into an infinite loop (e.g. dirA/linkB points to ../dirB, but dirB/linkA points to ../dirA, and now you're stuck).