mirror of
https://github.com/clechasseur/pathcopycopy.git
synced 2026-04-25 12:15:58 +03:00
[GH-ISSUE #99] [FEATURE] Add way to follow symbolic link #98
Labels
No labels
bug
duplicate
enhancement
enhancement
enhancement
fixed
help wanted
help wanted
invalid
pull-request
question
waiting for input
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/pathcopycopy#98
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @csm10495 on GitHub (Dec 12, 2019).
Original GitHub issue: https://github.com/clechasseur/pathcopycopy/issues/99
Originally assigned to: @clechasseur on GitHub.
Is your feature request related to a problem? Please describe.
I have made a link using
mklink /d, and would like an option to get the qualified path (including where the symlink actually points to). UNC path currently resolves via the symlink instead of the location.Describe the solution you'd like
New option to get UNC path (and resolve symlinks)
Describe alternatives you've considered
Just using UNC
Additional context
Here is an example:
I moved my .minecraft folder from Roaming/ to Y:/.minecraft
Then I did
mklink /D "Roaming/.minecraft" "Y:/.minecraft"If I am in Roaming/.minecraft and click a folder (say Roaming/.minecraft/Folder), I can't come up with a way to get the Y:/.minecraft/Folder path instead of Roaming/.minecraft/Folder.
@csm10495 commented on GitHub (Dec 12, 2019):
The feature I'm requesting is similar to this feature of Pathlib in python: https://docs.python.org/3/library/pathlib.html#pathlib.Path.resolve
@csm10495 commented on GitHub (Dec 12, 2019):
This function seems to auto-resolve the symlinks: https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlew. I wonder if combining UNC with calling this function would be enough to get it all the time.
@clechasseur commented on GitHub (Dec 12, 2019):
I'll remove "directory" from the title, since this could also apply to file links I think.
@clechasseur commented on GitHub (Jan 1, 2020):
Should be possible to identify a symbolic link through this function:
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfileattributesexa
and looking for FILE_ATTRIBUTE_REPARSE_POINT.
@clechasseur commented on GitHub (Jan 3, 2020):
This has been implemented in the
feature/post-winxpbranch and will be part of the next major release (tentatively labeled "18.0").