“octo pack” does url encoding of file names, eg. converts space in file name into %20
When using “unzip” on target machine this conversion remains, which is causing problems.
Is there a way to keep the file names as they are?
Hi Jürgen,
Thanks for getting in touch! What you are describing should not be the case.
Are you able to please provide us a full deployment log http://docs.octopusdeploy.com/display/OD/Get+the+raw+output+from+a+task
Also some screenshots of inside your package, and then the files on the server.
Really any extra information or examples so we could replicate this or find where the error is happening.
Thanks!
Vanessa
Hi Vanessa,
I’m seeing this behaviour as well, but only if I grab the package file off the NuGet server, rename it to .zip and extract it, e.g. using WinZip.
When deploying in Octopus, the “%20” file/directory names are correctly un-escaped back to spaces.
Perhaps the “nuget pack” command is responsible for the encoding of the names in this way?
Dan
Hi Dan,
Thanks for that explanation.We hadn’t seen anything like it using all the Octopus processes.
So really it isn’t an issue with anything that Octopus does, but if you take NuGet package and mess with it a bit.
Is there a reason for running such a process? Or is it a case of wanting to reuse the package?
Vanessa
Hi Vanessa,
Not really, I just wanted to give a bit of context to what Jurgen was talking about so you didn’t think it was something wrong with Octopus 
Indeed if you expand the .nupkg file in TeamCity (i.e. on the Artifacts tab of a completed build), the same thing occurs: spaces get escaped with “%20”. I’d argue that that’s an issue in TC though.
Cheers
Dan
Hi Dan,
Thanks so much for this info. We were a bit stumped on where to start, and hoped the logs would show us what process was being called.
But it does explain what could have happened. Thanks heaps for letting us know what you found so now we know how to replicate and where to start looking (in case its part of a template from the library or something).
Vanessa
Hello! We just ran into this same issue after telling folks on the team that “yeah, you can just grab the nuget packages and unzip them and they work”. That only actually works if none of the files in the package contain spaces in their filenames. If they do, a regular unzip program will extract them with “%20” instead of spaces.
This looks to be default behavior built into nuget so not any fault of Octopus. One workaround is instead of using a regular unzip program, use command line nuget.exe to extract the package wherever you want using:
nuget install Foo.Package -Source C:\Wherever -OutputDirectory C:\Foo