PnP-PowerShell
PnP-PowerShell copied to clipboard
Add-PNPFile cannot uploads files with an & in the file name.
###Notice: many issues / bugs reported are actually related to the PnP Core Library which is used behind the scenes. Consider carefully where to report an issue:###
- Is the issue related to the cmdlet itself, its parameters, the syntax, or do you suspect it is the code of the cmdlet that is causing the issue? Then please continue reporting the issue in this repo.
Reporting an Issue or Missing Feature
When I use Add-PNPFile with an ampersand in the file name I receive an error even though SPO support the filename when uploaded.
Expected behavior
File to successfully upload.
Actual behavior
Steps to reproduce behavior
Add-PnPFile -Path "C:\demo\101 Reasons everyone loves Shane & hates Todd.pptx" -Folder fileshare
Which version of the PnP-PowerShell Cmdlets are you using?
- [ ] PnP PowerShell for SharePoint 2013
- [ ] PnP PowerShell for SharePoint 2016
- [ X] PnP PowerShell for SharePoint Online
What is the version of the Cmdlet module you are running?
2.16.1706.1
How did you install the PnP-PowerShell Cmdlets?
- [ ] MSI Installed downloaded from GitHub
- [x ] Installed through the PowerShell Gallery with Install-Module
- [ ] Other means
Confirm ... I'm having exactly the same issue with you :(
Same issue ! And I the same issue can be reproduce with a Site Page and List Name too.
Try escaping the URL?
It appears the core might have the SharePoint on-prem character limitations implemented despite SharePoint Online not being as restrictive. Hoping that maybe they can be broken apart so SPO admins won't be impacted by this limitation.
Same issue with the % sign
Hi @RoelVB, could you try to use this char "&" more over than this one "&" ?
If you copy/past this two chars into "VSCode" for example, you'll can see that are not really the same. And the first one is allowed in to an URL but not the other one for my part.
It a good idea, but no solution
- The normal '&' in de filename and your '&' in the command gives a "File not found"
- Your '&' in both the filename and the command does work, but looks weird in the filename (explorer and online)
So renaming all the files to the weird '&' could be a workaround.
A real solution it’s not easy with this special char. First of all, this char is mostly used for the Web and URL and because PnP use some Web Services / CSOM that use the Web standard this char is not really recommended even for a filename.
So, if the other char that I suggested previously an help you it is perfect but I think the best solution is to avoid special char in to filename (^, %, &, all accents, etc.)
For french it is difficult to avoid accents.... Could we find a solution where the title is html encoded or some special code to support é èà etc
Seems like a similar issue is fixed for "Copy" routine but not for "Add": https://github.com/SharePoint/PnP-PowerShell/issues/1051
It also fails with Apply-PnPProvisioningTemplate command as far as I'm concerned
For anyone stumbling upon this - an easy workaround is to upload the file using a temporary file name, and then updating the FileLeafRef using Set-PnPListItem or Move-PnPItem .
$file = Add-PnPFile -Folder $folder -Path ".\temporary_fake_name.tmp"
Move-PnPFile -SiteRelativeUrl "$folder\temporary_fake_name.tmp" -TargetUrl "$library\$folder\test $ test.docx" -OverwriteIfAlreadyExists -Force
Unfortunately, there is no workaround for Apply-PnPProvisioningTemplate
Any update?, seeing the same issue with % in a folder name when calling CreateDocumentSetAsync
Edit:
From a look at the pnp core code @ https://github.com/pnp/PnP-Sites-Core/blob/3255343e2e8924227be15b1dcdbd2bea0aa44c60/Core/OfficeDevPnP.Core/Utilities/UrlUtility.cs#L15 The code is blocking more than it should [\#%*/:<>?+|""]
When according to MS the unsupported characters are " * : < > ? / \ | Reference: https://support.microsoft.com/en-us/office/invalid-file-names-and-file-types-in-onedrive-and-sharepoint-64883a5d-228e-48f5-b3d2-eb39e07630fa#invalidcharacters
Can this be escalated to the team to resolve? Thanks