You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't know if this is intended or not, but it's causing my issues because on Mac OS /tmp is a symbolic link to /private/tmp. On most Unix-y OSs and in AWS Lambdas it is just a regular directory.
The problem comes from mkdir.js:72, or thereabouts where the check for a directory does an fs.lstat (which treats a symlink as a file) instead of an fs.stat (which treats it as a directory).
Just wondering if there's a good reason for preferring lstat to stat? Just curious really, since it's mildly inconvenient (yes I know I should probably use os.tmpdir()).
The text was updated successfully, but these errors were encountered:
stkb
added a commit
to stkb/node-tar
that referenced
this issue
May 25, 2019
I've run into the same problem when using npm link with a package that downloads a binary straight into its own directory (which is a symlink because of npm link). Have created #214 to fix it.
Hi,
I don't know if this is intended or not, but it's causing my issues because on Mac OS /tmp is a symbolic link to /private/tmp. On most Unix-y OSs and in AWS Lambdas it is just a regular directory.
The problem comes from mkdir.js:72, or thereabouts where the check for a directory does an
fs.lstat
(which treats a symlink as a file) instead of anfs.stat
(which treats it as a directory).Just wondering if there's a good reason for preferring lstat to stat? Just curious really, since it's mildly inconvenient (yes I know I should probably use
os.tmpdir()
).The text was updated successfully, but these errors were encountered: