[fs.cp] fails with ERR_FS_EISDIR on Windows Powershell

[c-vetter]

Version

v16.17.0, v18.9.0

Platform

Microsoft Windows NT 10.0.19044.0 x64

Subsystem

No response

What steps will reproduce the bug?

In Powershell:

$ node
Welcome to Node.js v16.17.0.      
Type ".help" for more information.
> require(`fs`).cp(`B:`, `A:\\test`, (e,r)=>{if(e)throw e;console.log(r)})
undefined
> Uncaught:
SystemError [ERR_FS_EISDIR]: Path is a directory: cp returned EISDIR (\\?\B:\ is a directory (not copied)) \\?\B:\
    at __node_internal_captureLargerStackTrace (node:internal/errors:477:5)
    at new SystemError (node:internal/errors:238:5)
    at new NodeError (node:internal/errors:349:7)
    at getStatsForCopy (node:internal/fs/cp/cp:213:11) {
  code: 'ERR_FS_EISDIR',
  info: {
    message: '\\\\?\\B:\\ is a directory (not copied)',
    path: '\\\\?\\B:\\',
    syscall: 'cp',
    errno: 21,
    code: 'EISDIR'
  },
  errno: [Getter/Setter: 21],
  syscall: [Getter/Setter: 'cp'],
  path: [Getter/Setter: '\\\\?\\B:\\']
}

$ node
Welcome to Node.js v18.9.0.
Type ".help" for more information.
> require(`fs`).cp(`B:`, `A:\\test`, (e,r)=>{if(e)throw e;console.log(r)})
undefined
> Uncaught:
SystemError [ERR_FS_EISDIR]: Path is a directory: cp returned EISDIR (\\?\B:\ is a directory (not copied)) \\?\B:\
    at __node_internal_captureLargerStackTrace (node:internal/errors:484:5)
    at new SystemError (node:internal/errors:244:5)
    at new NodeError (node:internal/errors:355:7)
    at getStatsForCopy (node:internal/fs/cp/cp:211:11) {
  code: 'ERR_FS_EISDIR',
  info: {
    message: '\\\\?\\B:\\ is a directory (not copied)',
    path: '\\\\?\\B:\\',
    syscall: 'cp',
    errno: 21,
    code: 'EISDIR'
  },
  errno: [Getter/Setter: 21],
  syscall: [Getter/Setter: 'cp'],
  path: [Getter/Setter: '\\\\?\\B:\\']
}

How often does it reproduce? Is there a required condition?

Happens every time. Both drives are external, connected via USB.
Source can also be a subdirectory, analogous error.

I generally use Powershell Core, not the built-in Powershell.
But the same happens there.

What is the expected behavior?

Copy should proceed normally. My understanding is that I'm expected to give a root directory for the copy operation, right?

What do you see instead?

See reproduction above.

Apart from the error itself, I find the path strings weird. Don't recall having seen that \\?\ before.
That stuff is also given to the filter function.

Additional information

This was triggered by jprichardson/node-fs-extra#965 (comment)

[bnoordhuis]

You need to pass { recursive: true } to fs.cp(). The default is false.

Don't recall having seen that \?\ before.

They're long paths. Without the qualifier you can't manipulate paths longer than 260 bytes.

[c-vetter]

Okay, tried it. That works, but it still seems wrong to me.

First, this is the only description in the official docs, sync/async depinding on which version one looks at:

(A)synchronously copies the entire directory structure from src to dest, including subdirectories and files.

When copying a directory to another directory, globs are not supported and behavior is similar to cp dir1/ dir2/.

To me this very much says that I am actually expected to give directories, not files, as src and dst.

Second, if I don't want to recurse, I now have to go through the whole trouble of reading the directory's contents, filtering by type, and then calling copyFile or cp. I know that that's not new but actually the status quo.

In conclusion, I'd like to request:

1. that cp either just works with directories (preferred), or adds an option like directory <boolean=false>
2. that the docs clearly reflect how the behavior changes according to what type src and dst are (see fs-extra/copy)

Is this ok here or should I open a new ticket for the request?

[bnoordhuis]

It's still marked as experimental so you can just open a pull request with your proposed changes. Not everyone may agree with that change but you won't know until you try.

Documentation pull requests are always welcome, of course.

[c-vetter]

They're long paths. Without the qualifier you can't manipulate paths longer than 260 bytes.

Thanks for the info 🙂

It's still marked as experimental so you can just open a pull request with your proposed changes. Not everyone may agree with that change but you won't know until you try.

Documentation pull requests are always welcome, of course.

Ok, I'll see when and what I can do.

Closing this now, since it's not strictly a bug.