8000 New-Item symlinks cannot be created if destination (target) is non-existent or not accessible · Issue #9067 · PowerShell/PowerShell · GitHub
[go: up one dir, main page]
Skip to content

New-Item symlinks cannot be created if destination (target) is non-existent or not accessible #9067

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.

Sign up for GitHub

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

Jump to bottom
8000 Closed
msftrncs opened this issue Mar 5, 2019 · 12 comments
Closed

New-Item symlinks cannot be created if destination (target) is non-existent or not accessible #9067

msftrncs opened this issue Mar 5, 2019 · 12 comments
Labels
Area-FileSystem-Provider specific to the FileSystem provider Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a Resolution-No Activity Issue has had no activity for 6 months or more WG-Cmdlets-Management cmdlets in the Microsoft.PowerShell.Management module

Comments

@msftrncs
Copy link
Contributor
msftrncs commented Mar 5, 2019 •
edited
Loading

Steps to reproduce

new-item -type symboliclink -name "hello" -target "Z:\"

Because I have to execute this as an administrator, my Z: drive is not attached, and so PowerShell responds with an error.

new-item : Cannot find drive. A drive with the name 'Z' does not exist.
At line:1 char:1
+ new-item -type symboliclink -name "hello" -target "Z:\"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (Z:String) [New-Item], DriveNotFoundException
+ FullyQualifiedErrorId : DriveNotFound,Microsoft.PowerShell.Commands.NewItemCommand

It appears this was thought to be fixed in #801, but evidently it didn't include non-existent drives.

Instead I have to resort to CMD MKLINK.

cmd
> mklink /D "hello" "Z:\"
> exit

Environment data

Name                           Value
----                           -----
PSVersion                      6.2.0-rc.1
PSEdition                      Core
GitCommitId                    6.2.0-rc.1
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Edit 1: fixed spellings, changed parameter to '-target'.
@msftrncs msftrncs added the Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a label Mar 5, 2019
@msftrncs msftrncs changed the title New-Item symlinks cannot be created if destination (value) is to non-existant drive New-Item symlinks cannot be created if destination (target) is to a non-existent drive Mar 6, 2019
@msftrncs
Copy link
Contributor Author
msftrncs commented Mar 6, 2019 •
edited
Loading

I think this issue might have to do with symbolic links need to know if it is a directory or a file based symlink. MKLINK requires specifying the purpose of the symbolic link. PowerShell is probably trying to find the target so that it can determine the type of link from the target. That doesn't work when the target cannot be accessed at that time.

I also tested creating a symbolic link to a non-existent server via a UNC path and got the same results, except that it could not find 'the network path', so I don't think it has to do with drives as I originally though.

This might require new enumerations for -itemtype (type) to bypass the target lookup. I imagine this is not required for unix, and so this is probably a Windows only issue.

@msftrncs msftrncs changed the title New-Item symlinks cannot be created if destination (target) is to a non-existent drive New-Item symlinks cannot be created if destination (target) is non-existent or not accessible Mar 6, 2019
@msftrncs
Copy link
Contributor Author
msftrncs commented Mar 6, 2019

#2915 seems to have a good read on this … but I am not sure what happened along the way.

@iSazonov iSazonov added the WG-Engine-Providers built-in PowerShell providers such as FileSystem, Certificates, Registry, etc. label Mar 6, 2019
@mklement0
Copy link
Contributor
mklement0 commented Mar 6, 2019 •
edited
Loading

This is what happened (quoting @joeyaiello):

Well, it looks like your PR (#3509) is doing the right thing for now, If people desperately need directory symlinks to non-existent targets, we'll figure it out then.

The status quo:

  • You can create symlinks to nonexistent targets, except if the target path starts with a nonexistent drive / UNC share, which prompted creation of this issue, and which is a bug that should be fixed.

  • When creation of a symlink with a nonexistent target succeeds, currently a file symlink is invariably created - in the absence of being able to infer whether the target is a file or a directory.

As you state, a proper fix requires some way to explicitly indicate the type of a nonexistent target (and, indeed, it wouldn't be required on Unix-like platforms).

Building on your idea to introduce new -ItemType enumeration values, we could do the following:

  • Introduce FileSymlink and DirectorySymlink values in addition to Symlink.

    • If FileSymlink or DirectorySymlink are used and the target exists but doesn't match the requested type, report an error.

  • Additionally, given that directory symlinks are far more common than file symlinks, we could change the default (if only Symlink is used) to a directory symlink on Windows - though that is technically a breaking change.

@msftrncs
Copy link
Contributor Author
msftrncs commented Mar 6, 2019

Some thoughts:

  • Maybe instead of adding ItemType enumerations, it could allow an array of them, so that one could specify -itemtype directory, symboliclink to enforce the directory symbolic link. This would require new new enumerations, but would require changing the definition of the parameter, and also handling the otherwise limited use of an array parameter.
  • If the type of link has been suggested, but PowerShell still insists on checking to see if it is the right choice (MKLINK does not care) there will be a delay with non-existent or unreachable UNC paths, and possibly with others if the media is offline at the moment.
    -Ppreviously I had found it more common to make symlinks for directories, but recently I have been relying on them to symlink files for the purpose of replacing VS Code's default grammar/syntax files with my own custom ones, as I am not ready to figure out how to replace them with an extension that could break other desired functionality. I just have to replace the symlinks every time VS Code updates.

@mklement0
Copy link
Contributor

Good points, @msftrncs.

  • Not performing any existence or type-consistency check is an option, though I wish there were an opt-in/opt-out mechanism:

    • Arguably, an existence/consistency check should be performed by default, with a switch allowing opt-out, but that ship has sailed.
    • We could offer an opt-in, such as with a -Verify switch.

  • As for making -ItemType array-valued: that's also an option, though I worry that it is both less discoverable and more cumbersome; it also requires more work behind the scenes to rule out nonsensical combinations.

  • Point taken, re file symlinks - no compelling reason to change the default.

This was referenced Mar 12, 2019
Closed
Merged
@SteveL-MSFT SteveL-MSFT added this to the 7.0-Consider milestone May 5, 2019
@SteveL-MSFT SteveL-MSFT mentioned this issue May 5, 2019
Closed
@SteveL-MSFT SteveL-MSFT modified the milestones: 7.0-Consider, Future Oct 15, 2019
@jmg69
Copy link
jmg69 commented May 12, 2020

Hi.
When we create a symlink, is it possible that the lastwrite is the same as the original file? If yes how to do?

Thank you for your answer.

Best regards

Jean-Marc

@yecril71pl
Copy link
Contributor

When we create a symlink, is it possible that the lastwrite is the same as the original file? If yes how to do?

When you create a symbolic link to a unicorn, you cannot make a note of when said unicorn recently pooped.

@mklement0
Copy link
Contributor
mklement0 commented Jun 19, 2020 •
edited
Loading

@jmg69, that's not how the filesystem works; symlinks have their own last-write timestamps (which never change, unless you recreate the symlink).

Therefore, you must manually determine the target file (assuming it exists) and then query its properties:

$symlinkPath = './foo'
Get-Item (Get-Item $symlinkPath).Target # use (...).LastWriteTime to get just the last-write time

If a given path may or may not be a symlink:

$potentialSymlinkPath = './foo'
($item = Get-Item $potentialSymlinkPath).Target ? (Get-Item $item) : $item

But please note that this issue is about symlinks with non-existent targets.
If you have further questions, I suggest you use the following community resources:

@mklement0 mklement0 mentioned this issue Jul 1, 2020
Closed
@iSazonov iSazonov mentioned this issue Jul 2, 2020
Closed
14 tasks
This was referenced Apr 14, 2021
Merged
Closed
@iSazonov iSazonov added Area-FileSystem-Provider specific to the FileSystem provider WG-Cmdlets-Management cmdlets in the Microsoft.PowerShell.Management module and removed WG-Engine-Providers built-in PowerShell providers such as FileSystem, Certificates, Registry, etc. labels Dec 3, 2021
@microsoft-github-policy-service Microsoft GitHub Policy Service
Copy link
Contributor

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

2 similar comments
@microsoft-github-policy-service Microsoft GitHub Policy Service
Copy link
Contributor

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

@microsoft-github-policy-service Microsoft GitHub Policy Service
Copy link
Contributor

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

@microsoft-github-policy-service microsoft-github-policy-service bot added Resolution-No Activity Issue has had no activity for 6 months or more labels Nov 16, 2023
@microsoft-github-policy-service microsoft-github-policy-service bot added the Resolution-No Activity Issue has had no activity for 6 months or more label Nov 16, 2023
@microsoft-github-policy-service Microsoft GitHub Policy Service
Copy link
Contributor

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.

@microsoft-github-policy-service microsoft-github-policy-service bot removed this from the Future milestone Nov 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area-FileSystem-Provider specific to the FileSystem provider Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a Resolution-No Activity Issue has had no activity for 6 months or more WG-Cmdlets-Management cmdlets in the Microsoft.PowerShell.Management module
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Enable New-Item creates symlinks to non-existent targets iSazonov/PowerShell
6 participants
@mklement0 @yecril71pl @jmg69 @SteveL-MSFT @iSazonov @msftrncs
0