Broken symlinks should be copyable

[mbargiel]

• Operating System:
  Mac OS High Sierra 10.13.6
• Node.js version:
  8.11.3
• fs-extra version:
  7.0.0, 8.0.0 (actually 8.0.0-6-gf3a2eed)

I understand the current implementation always resolves symlinks when initiating a copy, which has the side-effect of causing the copy to file if the symlink is broken. There are even tests enforcing that, even if dereference is set to false. It seems to me that this is undesirable behavior. In fact, if I copy a directory A that contains a symlink pointing to a file outside of it into a different location, it works, but the copy of the directory cannot itself be copied because it now hosts a broken symlink. The following code snippet illustrates this.

const fse = require('fs-extra')

// Setup:
// target
// sourceDir/
//   target-symlink -> ../target
fse.ensureFileSync('target')
fse.ensureDirSync('sourceDir')
fse.symlinkSync('../target', 'sourceDir/target-symlink')

// Act
// nestedDir/
//   sourceDirCopy/
//     target-symlink -> ../target (broken symlink)
fse.ensureDirSync('nestedDir')
fse.copySync('sourceDir', 'nestedDir/sourceDirCopy')

// And this is where it breaks due to the constraint that source symlink targets *must* exist
fse.copySync('nestedDir/sourceDirCopy', 'sourceDirCopy')
>> Error: ENOENT: no such file or directory, stat 'nestedDir/sourceDirCopy/target-symlink'
    at Object.fs.statSync (fs.js:948:11)

This behavior does not match that of cp -R which, while I understand is a completely different implementation, is oblivious of broken symlinks (at least in this context).

[Karacayli]

I had the the same issue, that the whole copyingprocess failed/stopped because of a broken symlink. if you just want to copy the files without dereferncing the broken symlink, you can still use the renameSync function of fs. Ofc it would cool if this could be included in some way in moveSync.

[ramblingenzyme]

This is also a regression as I ran into this after upgrading fs-extra.

[zoe-mcelderry]

This is an issue for us as well and as the OP says, it does not match the standard cp -r functionality, which happily copies broken symlinks.

[RyanZim]

@jprichardson @manidlou @JPeer264 What are your thoughts here?

[manidlou]

I still don't understand the purpose of having a broken symlink but if that's what users want, I am fine with that!

[zoe-mcelderry]

Our use case is this... we copy a directory out of a docker container, do some modification (including copying the contents of a sub-directory, which may contain a symlink, to a different location within that directory) and then the whole directory gets copied back into the docker container.

So the symlink works when in the context of the docker container, but it links to something that is not there within the NodeJS app :-)

[mbargiel]

Well, I don't necessarily think there's a "purpose" to having broken symlinks, but I think the current behaviour introduces potential false failures. E.g. let's say I'm copying a folder hierarchy that contains a symlink to a folder deeper, or even to a file in the same directory. Depending on the order that the files and folders are recursively copied, the symlink could be copied before or after its target, resulting in either failure or success. (I unfortunately don't have time to set up a repro for this, it's just a case I thought of on top of my head.)

[lal12]

There are many use cases for broken symlinks. Most of them come down to what @zoe-mcelderry said, when working with them in a different context. I e.g. am building a linux rootfs from different locations in my repo, many of those symlinks are only valid after copying.

[RyanZim]

Fixed in #779