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

Copying a symlink does not preserve its type #626

Closed
oliversalzburg opened this issue Sep 24, 2018 · 9 comments
Closed

Copying a symlink does not preserve its type #626

oliversalzburg opened this issue Sep 24, 2018 · 9 comments

Comments

@oliversalzburg
Copy link

  • Operating System: Windows 10
  • Node.js version: 8.11.1
  • fs-extra version: 7.0.0

On Windows, when you attempt to copy a source, which is a symlink, fs-extra will always attempt to create a file symlink, regardless of what type of symlink the source is. This is an issue, as the result is unexpected and invalid.

Consider a source that is a junction (the most common type of link you're going to encounter on Windows). fs-extra will just invoke .symlink() without specifying a type, which will create a file symlink to the junction. The user will not be able to follow that link, because the junction isn't a file.

While you can work around the issue by passing dereference:true, I believe an attempt should be made to detect the type of link and then create a new link of the appropriate type.

@RyanZim
Copy link
Collaborator

RyanZim commented Sep 24, 2018

Agreed this should be fixed. @oliversalzburg are you up to submitting a PR fixing it? (copySync probably has this problem as well) Please base any PRs against the v8-dev branch.

@oliversalzburg
Copy link
Author

Yeah, I'd be happy to do it, but hit a roadblock right away. I don't see a clear way to make that distinction and I assume that's the reason why it hasn't be fixed already. Let's see if someone can give the right hint.

@oliversalzburg
Copy link
Author

I didn't find a way through NodeJS to detect the difference and I also didn't find any existing work out there regarding this matter.

So I wrote https://github.com/oliversalzburg/is-junction and now I'm wondering, if no better solution comes up, would it be acceptable to build a solution with that?

@RyanZim
Copy link
Collaborator

RyanZim commented Sep 24, 2018

IDK, could you just use fs.lstat or fs.stat to figure out if it's a file or directory link?

@oliversalzburg
Copy link
Author

@RyanZim I don't see how that would be possible when it comes to detecting junctions. lstat/stat will still be necessary to distinguish the two types of symlinks, but junctions will require external help.

I have been looking for solutions the past couple of hours and nobody was able to suggest a built-in method, but I'm open for ideas :)

@RyanZim
Copy link
Collaborator

RyanZim commented Sep 24, 2018

Sorry, I'm not very familiar with the windows filesystem, but how common are junctions?

@oliversalzburg
Copy link
Author

That depends on the user, but, with NodeJS developers, they are more common because npm will utilize them when you install modules in certain ways (npm link or when installing a package from a local path).

Because creating junctions (or any other type of link) is not possible through the Windows GUI without third-party tools, no type of link is really common though. If they exist, they are usually created by some kind of tool.

Regardless though, creating symlinks requires elevated permissions on Windows. So in any use case where a user or tool might want to link a directory to another place, they will almost always chose a junction over a symlink.

I hope that puts it into perspective :)

@danielehrhardt
Copy link

Could this be fixed?

@RyanZim
Copy link
Collaborator

RyanZim commented Sep 21, 2021

As per #912; fs.cp is coming to Node core, and we will be using their implementation, which is a fork of ours. If you would like this fixed, please file an issue to Node core about fs.cp.

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

No branches or pull requests

3 participants