Copying a symlink to a destination containing the same symlink should not fail

[mbargiel]

• Operating System:
  Mac OS High Sierra 10.13.6
• Node.js version:
  8.11.3
• fs-extra version:
  7.0.0

I ran into two problems related to copying symlinks: one is if the destination already exists, and one is if the resolved destination does not exist. (Both problems are distinct but closely related; in my case, attempting to fix one in my fork revealed the other... and caused a bunch of tests to fail, of course.)

1. In onLink, if the resolvedSrc and resolvedDest  are the same, the copy should be considered successful rather than throwing an error (consistent behavior with cp --preserve=links (cp -r on MacOS)). A consequence of this is that calling e.g. fse.copySync(src, dest) twice in a row throws if src is a directory containing a symlink somewhere inside its hierarchy, but otherwise works fine if there are no symlinks.

2. In onLink, the line (destStat === notExist) incorrectly checks for the resolved destination, which means that the following line (return fs.symlinkSync(resolvedSrc, dest)) can fail if dest exists but resolvedDest does not. That's because destStat is obtained from checkPaths/checkStats, which does not honor the opts.dereference option, i.e. uses stat rather than lstat.

Related: #638

[RyanZim]

Is this still an issue in v8?

[mbargiel]

Let me test.

[mbargiel]

Yes, it still doesn't work (I actually tested on master).

However, now I'm somewhat confused.

While setting up a local test "fixture", I found out that on macOS, the behaviour is not what I would expect: when recursively copying a directory, symlinks (whether broken or not) cannot overwrite a target symlink even when identical, and no amount of -f fixes this:

• Existing target directory symlinks are treated as directories and you get an error saying you're trying to copy a non-directory element on top of a directory (e.g. cp: cannot overwrite directory dest/dirlink with non-directory src/dirlink)
• Existing target file symlinks are equally not overwritable, with a different error message: cp: symlink: foo: File exists

While it would be nice to have it behave as I expected, it would deviate from what the OS shell itself does, so we can probably just close this Issue.

[RyanZim]

Closing as per above.