$timeFilePath fails with Space in path

[tmallwitz]

Hi,

Writing the lastExecutionTime Fails if the path has a space (for me it´s in OneDrive).
I fixed it by creating a profile.ps1 with this line:

$timeFilePath_Override = Join-Path -Path ([Environment]::GetFolderPath("MyDocuments")) -ChildPath "PowerShell\LastExecutionTime.txt"

This line should be part of the org script

[SKSniperSK]

Adding to this, why are there two locations in the script that define the $timeFilePath variable in different ways?

At the top we have:

powershell-profile/Microsoft.PowerShell_profile.ps1

Lines 6 to 7 in 59dde09

	# Define the path to the file that stores the last execution time
	$timeFilePath = [Environment]::GetFolderPath("MyDocuments") + "\PowerShell\LastExecutionTime.txt"

And later on we have:

powershell-profile/Microsoft.PowerShell_profile.ps1

Lines 64 to 71 in 59dde09

	# Define the path to the file that stores the last execution time
	if ($timeFilePath_Override){
	# If variable $timeFilePath_Override is defined in profile.ps1 file
	# then use it instead
	$timeFilePath = $timeFilePath_Override
	} else {
	$timeFilePath = "$env:USERPROFILE\Documents\PowerShell\LastExecutionTime.txt"
	}

I have moved the "MyDocuments" folder out of my profile, so the first declaration works but is getting overwritten with the non working second declaration. So either unify this into one declaration (and depending on which version is getting used I have to live with the fact that I probably need to declare the override) or at least do a Test-Path check in the "else" part of the second declaration to check if the existing $timeFilePath is already available before overwriting it.

/edit:

I just saw that there are/were more related issues and PR to this topic, it looks like #133 and #136 were both done about at the same time leading to the mentioned inconsistent duplicate code mentioned above (#136 copied the 'old' logic into the duplicate second part while #133 adjusted the first part to fix the issue with OneDrive using MyDocuments directly instead of going through the profile).

There is also already #165 to bring both parts back in line, so as soon as #165 has been accepted/merged, this issue here should also be resolved.