fsPromises.cp(...) inconsistencies and bugs

The fsPromises.cp and fs.cp methods are inconsistent with the sync version because they do not correctly accept Buffer file paths. This also means it also improperly handles non-UTF8 encoded filenames. The sync variation supports Buffer.

The method also does not appropriately validate inputs. Rather than throwing a proper Node.js type error when a Buffer is passed, it tries to use it and fails at another point deeper in the function.

The impl of the async version of the method is also needlessly structured differently from the sync version leading to a fair amount of duplicated and inconsistent code, making it difficult to fix the inconsistencies. The sync version was updated recently to move significant pieces to C++ while the async versions were not similarly updated.

Example:

fs.cpSync(Buffer.from('a'), Buffer.from('b'));  // works!

fs.cp(Buffer.from('a'), Buffer.from('b'), (err) => { /* ... */ });  // fails!

The error thrown is:

TypeError [ERR_INVALID_ARG_TYPE]: The "paths[0]" argument must be of type string. Received an instance of Buffer
    at resolve (node:path:1195:7)
    at normalizePathToArray (node:internal/fs/cp/cp:185:45)
    at isSrcSubdir (node:internal/fs/cp/cp:190:18)
    at checkPaths (node:internal/fs/cp/cp:110:32)
    at async cpFn (node:internal/fs/cp/cp:66:17)

fs.cp(...) is currently just a callbackified(...) version of fsPromise.cp(...), so fixing one should fix the other:

There are several fixes necessary: If Buffer is not going to be accepted, then the method should properly validate that the input src and dest are not Buffers and throw a proper ERR_INVALID_ARG_TYPE error. However, not accepting Buffer mean that the async versions of these will not properly handle non-UTF8 encoded file names. Ideally, the method would be updated to accept Buffer paths, but that means the normalizePathToArray method needs to be updated/refactored.

Second, the differences that were introduced when the sync version was updated to move chunks to C++ make it rather difficult to keep these methods in sync with each other. There is a strong possibility/likelihood of inadvertently introducing behavioral differences between the two that increase the likelihood of more inconsistencies being introduced in the future. We should probably move the entire implementation of the cp callback, cp promise, and cp sync methods into C++ if we're going to have any of the implementation in C++, having those eliminate duplicated logic as much as possible.

There is another bug in the implementation of these methods with regards to the options.filter option, which does not correctly handle the case in cpSync when the src and dest are passed as Buffer and when the children of copied directories are not UTF8 encoded file names. The differences in the implementation of the sync and async versions of the cp function make it quite difficult to introduce a consistent fix across the variations. The implementations should be reconciled and moved to C++ first, including the case where options.filter is called, before we can properly fix the options.filter implementation in a consistent way.

@nodejs/fs @dario-piotrowicz @anonrig

Beginne in node:internal/fs/cp/cp und verfolge normalizePathToArray, cpFn sowie die callback-, promise- und sync-Einstiegspunkte. Vergleiche deren Behandlung von Buffer-Pfaden und options.filter und überprüfe anschließend den vom sync-Implementierung verwendeten C++-Pfad. Als abgeschlossen gilt die Arbeit, wenn die drei Varianten eine konsistente Validierung und ein konsistentes Verhalten für Buffer- und Nicht-UTF-8-Pfade sowie eine übereinstimmende filter-Behandlung aufweisen.