fs.stat函數，用於在Windows中指向目錄的符號鏈接

Question

在我的Windows環境（x64）中，用於symlink指向目錄的fs.stat函數帶來了錯誤。

另一方面，在傳送帶（ia32）中，用於symlink指向目錄的fs.stat函數運行良好。

這就是為什么？ 哪種行為是正確的？

我的測試代碼的一部分是

it('Test 001 : fs.stat for symlink', function () {
  var target = path.resolve(workDir, 'sample1');
  console.log('target :' + target);
  fs.mkdirSync(target);                 // create directory
  var link = path.resolve(workDir, 'link1');
  console.log('link :' + link);
  fs.symlinkSync(target, link);         // create symlink to directory

  expect(function() {
    var stat = fs.statSync(link);       // checking symlink stat
    console.log(stat);
  }).not.toThrow();

});

有關所有代碼，請參見https://github.com/knight9999/WindowsSymbolicLinkCheck 。

在我本地環境中的結果是

Failures:
1) win symlink tests Test 001 : fs.stat for symlink
  Message:
    Expected function not to throw, but it threw Error: EPERM: operation not permitted, stat 'C:\Users\knaito\AppData\Local\Temp\appveyor-tests-winSymlinkTests-VcfaRo\link1'.
  Stack:
    Error: Expected function not to throw, but it threw Error: EPERM: operation not permitted, stat 'C:\Users\knaito\AppData\Local\Temp\appveyor-tests-winSymlinkTests-VcfaRo\link1'.
        at <Jasmine>
        at UserContext.<anonymous> (C:\Users\knaito\Documents\work\cordova-develop\WindowsSymbolicLinkCheck\spec\winSymlink.spec.js:24:12)
        at <Jasmine>

1 spec, 1 failure

傳送帶中的結果是

Started
target :C:\Users\appveyor\AppData\Local\Temp\1\appveyor-tests-winSymlinkTests-NsaPyJ\sample1
link :C:\Users\appveyor\AppData\Local\Temp\1\appveyor-tests-winSymlinkTests-NsaPyJ\link1
Stats {
  dev: 3567992900,
  mode: 16822,
  nlink: 1,
  uid: 0,
  gid: 0,
  rdev: 0,
  blksize: undefined,
  ino: 844424934502125,
  size: 0,
  blocks: undefined,
  atimeMs: 1537164694047.7703,
  mtimeMs: 1537164694047.7703,
  ctimeMs: 1537164694047.7703,
  birthtimeMs: 1537164694047.7703,
  atime: 2018-09-17T06:11:34.048Z,
  mtime: 2018-09-17T06:11:34.048Z,
  ctime: 2018-09-17T06:11:34.048Z,
  birthtime: 2018-09-17T06:11:34.048Z }
.

請參閱https://ci.appveyor.com/project/knight9999/windowssymboliclinkcheck 。

注意：我知道symlinkd或junction適用於Windows中的目錄。 然而fs.copy一個junction指向目錄中創建新的symlink （既不symlinkd也不junction ）自動。

Answer 1

我自己詳細發現了這個問題。

對於Windows 10， fs.statSync調用nodejs內部函數

INLINE static void fs__stat_impl(uv_fs_t* req, int do_lstat) {
  HANDLE handle;
  DWORD flags;

  flags = FILE_FLAG_BACKUP_SEMANTICS;
  if (do_lstat) {
    flags |= FILE_FLAG_OPEN_REPARSE_POINT;
  }

  handle = CreateFileW(req->file.pathw,
                       FILE_READ_ATTRIBUTES,
                       FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
                       NULL,
                       OPEN_EXISTING,
                       flags,
                       NULL);
  if (handle == INVALID_HANDLE_VALUE) {
    SET_REQ_WIN32_ERROR(req, GetLastError());
    return;
  }
  ...

在deps/uv/src/win/fs.c 。 參見https://github.com/nodejs/node/blob/9b292272ff3d71a0ebabe46d040346dbd34585db/deps/uv/src/win/fs.c#L1252 。

對於指向其他目錄的symlink CreateFileW返回INVALID_HANDLE_VALUE 。

但是對於Windows Server 2012 R2（與appveyor中的相同），此功能運行良好。

因此

node -e "console.log(fs.statSync('/path/to/symlink/pointing/other/directory`));"

為Windows 10帶來錯誤，對於Windows Server 2012 R2效果很好。

我的結論，我們應該避免symlink指向在Windows 10，其他目錄junction好。

Answer 2

如果執行文件位於ex：src / webpack /文件夾中，然后將其移至src /，然后在package.json中的腳本中執行命令，則它將起作用。