Based on the readme:
realpath: Resolve symlinks using realpath, defaults to true (note that if true, the file must exist previously)
This explains that the setting is true by default, and because /tmp is symlinked to /private/tmp on macOS, it produces this ENOENT problem whenever we try to use a lockfile in /tmp.
What is the official workaround for this? Disabling realpath works for me in testing. But I am unclear on what are the drawbacks of specifying realpath: false and why exactly this fails. Is realpath intended as a security measure or a convenience measure that has lower security?
I was beginning to think that manually creating the lockfile is what I'm supposed to do, but on second thought that seems to go against the notion of the lockfile itself...
Based on the readme:
This explains that the setting is true by default, and because
/tmpis symlinked to/private/tmpon macOS, it produces this ENOENT problem whenever we try to use a lockfile in/tmp.What is the official workaround for this? Disabling
realpathworks for me in testing. But I am unclear on what are the drawbacks of specifyingrealpath: falseand why exactly this fails. Isrealpathintended as a security measure or a convenience measure that has lower security?I was beginning to think that manually creating the lockfile is what I'm supposed to do, but on second thought that seems to go against the notion of the lockfile itself...