Move-Item fails while using a wildcard in destination

[PietJankbal]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Encountered in a script I'd like to use. Easy way to reproduce is like:

cd c:\users\my_name

$null > filename

Move-Item .\filename "C:\users\my_name\Deskto*"

Error: Move-Item: Invalid name.

In Powershell 5.1 this command succeeds just fine

Expected behavior

The file is moved to c:\users\my_name\Desktop

Actual behavior

Error: Move-Item: Invalid name.

Error details

none

Environment data

Name                           Value
----                           -----
PSVersion                      7.3.5

Visuals

No response

[StevenBucher98]

Able to reproduce, Mac also has a where it creates a file called Deskto* and the file I tried moving is gone from original location 😨

[mklement0]

The behavior goes back to at least v7.2.10, so this breaking change has been in effect for a while.

You could consider it a blessing in disguise, given that:

• The related Rename-Item cmdlet has seemingly always treated its -NewName argument as a literal (verbatim) path.

• Treating output paths as wildcard expressions has always been questionable to me, but things have been moving in the right direction:

  • In at least one context, a similar breaking change was deliberately made (a bucket 3 change: Make -OutFile param in web cmdlets to work like -LiteralPath #11701
  • Similarly, in another context an analogous change was green-lit, but has yet to be implemented: New-Item: When creating symbolic links (symlinks) / reparse points, the -Target path should always be treated as a *literal* path #13136 (comment)
  • For a list of all related issues, see When New-Item -Path is combined with -Name, the -Path argument is inappropriately treated as a wildcard expression #17106 (comment)

[PietJankbal]

Hi
I'm not exactly sure what your point is, but I would rather expect a behaviour similar to Powershell 5.1.
Are you trying to say this is a wonttfix?
I would appreciate that (simple) scripts built for Powershell 5.1 also could somehow run in Powershell Core.

For completeness I'll post the failing script line in powershell core (but succeeds in powershell 5.1):

Move-Item -Path "$toolsPath\cacert.pem" -Destination "$toolsPath\curl*\bin\curl-ca-bundle.crt" -Force

The "curl*" is the offending part

[mklement0]

I'm not exactly sure what your point is

If there's something unclear about my arguments, please address them specifically.
In short: I'm saying that treating the -Destination argument as a literal path is sensible, even if it amounts to a breaking change.

I would appreciate that (simple) scripts built for Powershell 5.1 also could somehow run in Powershell Core.

While that desire is understandable, given the many breaking changes that PowerShell Core - by design - introduced relative to the legacy Windows PowerShell edition, preserving backward compatibility isn't an end in itself.

Are you trying to say this is a wonttfix?

I have no say in what will or will not happen. I'm just a fellow user offering input.
And, for the reasons stated, I wouldn't consider reverting to the 5.1 behavior a fix.

[mklement0]

Given that based on your example it may not be obvious why disallowing wildcards in -Destination is called for, let me amplify a bit:

The problem that keeps coming up with is the unintended interpretation as wildcard patterns of meant-to-be literal file paths that contain [ and ]: say you have subfolders .\Pics[1] and .\Pics1 and you try Move-Item *.jpg -Destination .\Pics[1]. In Windows PowerShell, this will target the wrong directory, because wildcard .\Pics[1] matches Pics1, and that match is considered first.

In other words: what Move-Item appears to be doing in Windows PowerShell is to first look for a wildcard match and then, if none is found, fall back to literal interpretation of the path.

In many other cases - such as Invoke-WebRequest's -Target parameter in Windows PowerShell, only wildcard interpretation happens, so that something like Invoke-WebRequest https://example.org -OutFile foo[1].html simply fails ("the wildcard path foo[1].html did not resolve to a file.")

Fixing the Move-Item command requires awkward, non-obvious escaping: Move-Item *.jpg -Destination .\Pics``[1``] or Move-Item *.jpg -Destination '.\Pics`[1`]' or Move-Item *.jpg -Destination ([WildcardPattern]::Escape('.\Pics[1]'))

In the Invoke-WebRequest -Target case, a breaking change was deliberately made in PS Core to switch to literal interpretation only.
While the Move-Item change may not have been deliberate, it is beneficial for the same reason: avoiding the pitfalls and awkwardness of - invariable or situational - wildcard interpretation.

You can use a Get-Item call (with a positionally implied -Path argument) to make your command work, and doing so will continue to be necessary if the current behavior is retained:

Move-Item -Path "$toolsPath\cacert.pem" -Destination (Get-Item "$toolsPath\curl*\bin\curl-ca-bundle.crt") -Force

[PietJankbal]

Hi Michael,

Thanks for the clarification. I will ask the maker of the "curl-script" to change the failing line into the one that you provided, so that it is compatible with PS7. That is ok with me.

Should I close this issue then?

regards

[mklement0]

Glad to hear it, @PietJankbal.

I don't think you should close this issue yet, because I think an official decision should be made as to whether this seemingly inadvertent - or at least undocumented - change is to be kept (my personal vote is: yes).

And that decision will determine the nature of any documentation changes (which will be required either way).

[Hrxn]

Just for the record, and also just speaking as a fellow user offering input, I completely agree with @mklement0

It's a blessing in disguise, so to speak.

[JamesWTruher]

The WG discussed this and while we cannot immediately locate a PR where this was implemented, we do believe it to be proper behavior (as copy-item will produce an error in Windows PowerShell, copy-item and move-item are now behaving consistently with respect to each other). This appears to be a doc issue and I have opened MicrosoftDocs/PowerShell-Docs#10887 to address.