Path::homeDirectory(): asserts when run by Windows users without home directory

Hi @mosra,

summarizing gitter messages: It is possible to run applications on windows through system users without home directories. In this case CSIDL_PERSONAL does not known and SHGetFolderPathW() will not return S_OK, but rather E_INVALIDARG .

This means the assert that is assumed to never possibly fail can indeed fail:

corrade/src/Corrade/Utility/Path.cpp

Lines 581 to 583 in ba75f71

    
               /* There doesn't seem to be any possibility how this could fail, so just 
        
                  assert */ 
        
               CORRADE_INTERNAL_ASSERT(SHGetFolderPathW(nullptr, CSIDL_PERSONAL, nullptr, 0, h) == S_OK);

Expectation would be that this returns a null optional instead.

Best,
Jonathan

Interesting, apparently I overlooked this error case.

I have a fix locally, but would like to have an explicit test for it -- do you still have access to the home-less VM runner to explore a bit? In particular I'd like to know what environment variables are present there, especially %HOMEPATH% and %USERPROFILE%, or whether they're set to empty, to independently detect such case in a test. Thank you!

I seem to be unable to find documentation on what environment is present for local system/service accounts on Windows, hence I tried running a powershell script as a local service account to grep the environment. (Using this for the system account execution and this for retrieving the environment. The script is attached for reference.

That returned nothing at all, so I am suspecting that system/service accounts don't have access to the environment at all. This post hints and individual variables needing explicit access to environment variables, controlled by Windows registry values.

Powershell script for grepping the environment as system user

$ErrorActionPreference = 'Stop'

Clear-Host

$taskName = "it3xl_dummy_PowerShell_job"
# Unregister-ScheduledJob it3xl_dummy_PowerShell_job -Confirm:$false

$task = Get-ScheduledJob -Name $taskName  -ErrorAction SilentlyContinue
if ($task -ne $null)
{
    Unregister-ScheduledJob $task  -Confirm:$false
    Write-Host "Old $taskName job has been unregistered"; Write-Host;
}


$trigger = New-JobTrigger -AtStartup;

$options = New-ScheduledJobOption -StartIfOnBattery  -RunElevated;

Write-Host "Registering new $taskName job";
Register-ScheduledJob -Name $taskName  -Trigger $trigger  -ScheduledJobOption $options `
    -ScriptBlock {
    $somthing = Get-ChildItem env:
    Write-Host $something
}


#$accountId = "NT AUTHORITY\SYSTEM";
$accountId = "NT AUTHORITY\LOCAL SERVICE";
$principal = New-ScheduledTaskPrincipal -UserID $accountId `
    -LogonType ServiceAccount  -RunLevel Highest;

$psSobsSchedulerPath = "\Microsoft\Windows\PowerShell\ScheduledJobs";
$someResult = Set-ScheduledTask -TaskPath $psSobsSchedulerPath `
    -TaskName $taskName  -Principal $principal


Write-Host;
Write-Host "Let's show proofs that our PowerShell job will be running under the LocalSytem account"
$task = Get-ScheduledTask -TaskName $taskName
$task.Principal

Write-Host "Let's start $taskName"
Start-Job -DefinitionName $taskName | Format-Table

Write-Host "Let's proof that our PowerShell job was ran"
Start-Sleep -Seconds 3
Receive-Job -Name $taskName

Awesome, so for testing it might be enough to just check that %APPDATA% or %HOMEPATH% doesn't exist. I made an attempt on a fix and a test in 94f841e (on the ~~next~~ directory-home-graceful-fail branch, #141), could you try to run UtilityPathTest under the system account? The test should fail because I don't know what error message to accept, if you could then paste the whole output here that'd be great.

Thanks in advance! :)

	/* There doesn't seem to be any possibility how this could fail, so just
	assert */
	CORRADE_INTERNAL_ASSERT(SHGetFolderPathW(nullptr, CSIDL_PERSONAL, nullptr, 0, h) == S_OK);