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

Distinguishing between different types of links on Windows #1520

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

Distinguishing between different types of links on Windows #1520

oliversalzburg opened this issue Sep 24, 2018 · 12 comments

Comments

@oliversalzburg
Copy link

oliversalzburg commented Sep 24, 2018

  • Node.js Version: 8.12.0
  • OS: Windows 10
  • Scope (install, code, runtime, meta, other?): runtime
  • Module (and version) (if relevant): fs

On Windows, when we create a symlink, we are given the options to create a file or directory symlink or a junction. How can I determine if an existing entity is a file or directory symlink or a junction?

stats.isSymbolicLink() will return true for all 3 types and I did not find an API that would provide more detail.

This is in reference to: jprichardson/node-fs-extra#626

@benjamingr
Copy link
Member

@nodejs/windows

@Hakerh400
Copy link

@nodejs/windows

According to the collaborator guide, the team name is @nodejs/platform-windows

@benjamingr
Copy link
Member

benjamingr commented Sep 25, 2018

@Hakerh400 you're right, I'm just on holiday and not on my PC :) @nodejs/platform-windows for an actual ping. Thanks for catching this!

(Pretty funny since I was a team member for ~2 years 😅)

@tniessen
Copy link
Member

tniessen commented Jan 8, 2019

I'm not sure whether it makes sense to implement this. Anyway, all three types are probably of type FILE_ATTRIBUTE_REPARSE_POINT and this document might be relevant for distinguishing them.

@oliversalzburg
Copy link
Author

I have already implemented this at https://github.com/oliversalzburg/is-junction

@tniessen
Copy link
Member

tniessen commented Jan 9, 2019

@oliversalzburg You seem to be doing exactly what I suggested :) Is this issue resolved then?

@oliversalzburg
Copy link
Author

@tniessen I was hoping for a solution in Node itself 😢

@gireeshpunathil
Copy link
Member

@oliversalzburg - is this resolved? please feel to contribute as a PR, if you have specific proposals to improve!

@oliversalzburg
Copy link
Author

@gireeshpunathil I have no reason to believe that it was resolved and nobody qualified ever responded to my inquires.

@gireeshpunathil
Copy link
Member

@oliversalzburg - I checked the code and see what you are saying. Basically it is a good to have feature (to further specialize on the link info); but prospects of being implemented in core may depend on strength of the use case and number of people asking for it, and hence I suggested a PR in the previous comment.

@tniessen
Copy link
Member

nobody qualified ever responded to my inquires.

@oliversalzburg This kind of makes it sound as if the person who did respond, me, is unqualified. I will kindly assume that you did not actually mean to imply that.

I opened libuv/libuv#2384. libuv is responsible for platform-specific IO.

@oliversalzburg
Copy link
Author

@tniessen I posted here in the hope to learn how to achieve this in NodeJS, because I didn't think that this is impossible. I didn't read your response as a definitive "This is currently not possible", so I assumed we were still waiting for someone who knows how to do it.

Given that months had passed since I asked about this, I already went ahead and wrote the module I linked, which wasn't an acceptable solution for the node-fs-extra members and the issue remains unresolved.

I doubt many people would ask for the ability to distinguish link types explicitly, but it ultimately leads to extremely hard to debug issues when using the affected code in node-fs-extra.

Thanks for opening the linked issue.

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

No branches or pull requests

5 participants