Azure-pipelines-tasks: [error]An object at the specified path C:\Users\OD42B~1.BOR does not exist

[oleksabor]

Type: Bug

Enter Task Name: PublishSymbols@2

Environment

• Server - Azure Pipelines

account name, team project name, build definition name/build number:
quipu-cwnet
packages
impersonationRemoting/#20190604.6

• Agent - Private:

WindowsServer 2012 R2 6.3 build 9600
agent version 2.150.3

Issue Description

PublishSymbols task fails to execute with error

[error]An object at the specified path C:\Users\OD42B~1.BOR does not exist

when private agent is running as windows service using o.borodai domain user. I've tried to understand how OD42B~1.BOR is related to the o.borodai but failed.
Task works fine if network service account is used to run Azure pipelines agent service

Task logs

logs_1406.zip

Troubleshooting

Checkout how to troubleshoot failures and collect debug logs: https://docs.microsoft.com/en-us/vsts/build-release/actions/troubleshooting

Error logs

##[debug]Asserting leaf path exists: 'E:\buildagent\network\_work\_tasks\PublishSymbols_0675668a-7bba-4ccb-901d-5ad6554ca653\2.0.14\pdbstr.exe'
##[debug]Leaving Invoke-IndexSources.
##[debug]Leaving E:\buildagent\network\_work\_tasks\PublishSymbols_0675668a-7bba-4ccb-901d-5ad6554ca653\2.0.14\PublishSymbols.ps1.
##[debug]Caught exception from task script.
##[debug]Error record:
##[debug]Push-Location : An object at the specified path C:\Users\OD42B~1.BOR does not exist.
##[debug]At E:\buildagent\network\_work\_tasks\PublishSymbols_0675668a-7bba-4ccb-901d-5ad6554ca653\2.0.14\IndexHelpers\IndexFunctions.ps1:26 char:9
##[debug]+         Push-Location $env:TEMP
##[debug]+         ~~~~~~~~~~~~~~~~~~~~~~~
##[debug]    + CategoryInfo          : InvalidArgument: (:) [Push-Location], PSArgument    Exception
##[debug]    + FullyQualifiedErrorId : Argument,Microsoft.PowerShell.Commands.PushLocat    ionCommand
##[debug] 
##[debug]Script stack trace:
##[debug]at Invoke-IndexSources, E:\buildagent\network\_work\_tasks\PublishSymbols_0675668a-7bba-4ccb-901d-5ad6554ca653\2.0.14\IndexHelpers\IndexFunctions.ps1: line 26
##[debug]at <ScriptBlock>, E:\buildagent\network\_work\_tasks\PublishSymbols_0675668a-7bba-4ccb-901d-5ad6554ca653\2.0.14\PublishSymbols.ps1: line 138
##[debug]at <ScriptBlock>, <No file>: line 1
##[debug]at <ScriptBlock>, <No file>: line 22
##[debug]at <ScriptBlock>, <No file>: line 18
##[debug]at <ScriptBlock>, <No file>: line 1
##[debug]Exception:
##[debug]System.Management.Automation.PSArgumentException: An object at the specified path C:\Users\OD42B~1.BOR does not exist.
##[debug]   at Microsoft.PowerShell.Commands.FileSystemProvider.NormalizeThePath(String basepath, Stack`1 tokenizedPathStack)
##[debug]   at Microsoft.PowerShell.Commands.FileSystemProvider.NormalizeRelativePathHelper(String path, String basePath)
##[error]An object at the specified path C:\Users\OD42B~1.BOR does not exist.

[github-actions[bot]]

This issue is stale because it has been open for a year with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days

[phasmatic2k]

I have the exact same problem. Can anybody reopen the issue ?

[bormm]

We have the same issue here and some colleagues now wasted some hours as the other guys. So I analyzed it a bit and it was not very hard to find this tricky thing. So please MS fix it!
The good thing is, that it is easy to fix. But first some words about the issue:

The issue in Windows

It seems there is some "hack" in Windows, which fills the TEMP and TMP variable in some cases with the short name representation of the real path. So if you set TEMP to "%USERPROFILE%\AppData\Local\Temp" and USERPROFILE does contains some special characters, you get the shortened "8.3" path. Just check this out: Why does the system convert TEMP to a short file name?

Sample:
TEMP="c:\users\john\" -> no issue
TEMP="c:\users\johnma.yer\" -> no issue
TEMP="c:\users\johnm.ayer\" -> "C:\Users\JOHNM~1.AYE" -> boom
That's because after the dot more than 3 characters are following.

That's _not really_ an issue, as it is intended by Microsoft. But of course viewing this more from a bird view, even this "intended" thing is not common known, also not common known to Microsoft guys. So... I would still call this some kind of issue.

The issue in PowerShell

As with most errors, there are several problems that make them appear:
PowerShell seems to unable to switch into a directory if the name is the shortened one.
If you try to Set-Location on such a shortened path, you get this object does not exist error, which is not the same as "path does not exist":

Here are the unfixed and also unanswered PowerShell issues:

• https://github.com/PowerShell/PowerShell/issues/7760
• https://github.com/PowerShell/PowerShell/issues/2369
  A short search shows very fast, that there are 530.000 pages related with this PS issue. Unfortunately as I wrote, it was never fixed.

The issue in PublishSymbols

So as TEMP and TMP are no safe variables in PowerShell, they shouldn't be used in any PowerShell Code. So this is the top layer issue here, even if the two other issue layers are also all in Microsoft components.
So this and all usages of TEMP and TMP has to changed:
https://github.com/microsoft/azure-pipelines-tasks/blob/e2387b5ec14e14fcfa487800420193e0b20b3f17/Tasks/PublishSymbolsV2/IndexHelpers/IndexFunctions.ps1#L26.

To one of the known working variants:

• Push-Location ([System.IO.FileInfo]$env:TEMP).FullName
• or much better: Push-Location ([System.IO.Path]::GetTempPath())

Can you recheck this issue please @bryanmacfarlane @aasim @damccorm @ds-ms ?

[phasmatic2k]

I found a workaround, set indexSources to false.

[bormm]

I found a workaround, set indexSources to false.

Thanks for this hint!
It is of course also possible to set TEMP for the user running the agent to a value that is not affected by this issue, like "c:\user-temp" or something.

[phasmatic2k]

I found a workaround, set indexSources to false.

Thanks for this hint!
It is of course also possible to set TEMP for the user running the agent to a value that is not affected by this issue, like "c:\user-temp" or something.

Thanks, this might be easier then my existing workaround 😀