Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken symlinks should be copyable #638

Closed
mbargiel opened this issue Oct 16, 2018 · 9 comments
Closed

Broken symlinks should be copyable #638

mbargiel opened this issue Oct 16, 2018 · 9 comments
Labels
Milestone

Comments

@mbargiel
Copy link
Contributor

@mbargiel mbargiel commented Oct 16, 2018

  • 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).

@mbargiel mbargiel changed the title Cannot copy a broken symlink Broken symlinks should be copyable Oct 16, 2018
@Karacayli
Copy link

@Karacayli Karacayli commented Jan 24, 2019

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
Copy link

@ramblingenzyme ramblingenzyme commented Jun 6, 2019

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

@zoe-mcelderry
Copy link

@zoe-mcelderry zoe-mcelderry commented Jan 22, 2020

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
Copy link
Collaborator

@RyanZim RyanZim commented Jan 30, 2020

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

@manidlou
Copy link
Collaborator

@manidlou manidlou commented Feb 4, 2020

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
Copy link

@zoe-mcelderry zoe-mcelderry commented Feb 4, 2020

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
Copy link
Contributor Author

@mbargiel mbargiel commented Feb 4, 2020

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
Copy link

@lal12 lal12 commented Aug 14, 2020

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
Copy link
Collaborator

@RyanZim RyanZim commented Apr 1, 2021

Fixed in #779

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

7 participants