Get-PWFolders Folderpath Case sensitivity

In your first example, you are missing the parent folder.

$id = "alpena tsc\119813\1 - base plans"

vs

$id = "-north region\alpena tsc\119813\1 - base plans"

Are we sure this is a case sensitive issue? My first thought is you are getting an error because you are missing part of the path.

That would be an easy fix, however the only change between the "first example" and the "second example" is case. I did try that though...

PS C:\PS> $id = "documents\-alpena tsc\119813\1 - base plans"

PS C:\PS> Get-PWFolders -FolderPath $id -JustOne
WARNING: 'documents\-alpena tsc\119813\1 - base plans' is not a valid folder name

====================(With Root and the case change):

PS C:\PS> $id = "Documents\-North Region\Alpena TSC\119813\1 - Base Plans"

PS C:\PS> Get-PWFolders -FolderPath $id -JustOne
WARNING: 'Documents\-North Region\Alpena TSC\119813\1 - Base Plans' is not a valid folder name

=====================(No Luck)

However without "the root" but with the case changes:

PS C:\PS> $id = "-North Region\Alpena TSC\119813\1 - Base Plans"

PS C:\PS> Get-PWFolders -FolderPath $id -JustOne

ProjectID : 589415
Name : 1 - Base Plans
Description : 1 - Base Plans
FullPath : -North Region\Alpena TSC\119813\1 - Base Plans
FolderDepth : 4

seems to work...

Thanks.

If you see anything I missed, or have another thought, ...I am all about trying! (only a fool is "positive"  :-)  )

Thanks Brandon!

Bob

Ah nice. I didn't realize you could trim on any character I normally only use it for white space. Turns out I can do the replace before the trim and do the entire thing in one go.

Also realized I was doing a few too many comparisons with both the -contains test and the where extraction. So I just do the where and test if that succeeded.

And finally removed that spurious $I = 0, which I know I was going to use as an loop counter but totally forget why I wanted one, and never used it.

Final version gets down to 13 seconds (but this is running this morning with users on the system vs. last night so might be faster)

$FindPath = "Top Folder\Sub-Folder 1\Another Sub\Way\Deep\In\The\Weeds\"

# 1. Fix paths that have slashes instead of backslashes
# 2. Trim leading and trailing backslashes
# 3. Make each folder name an array entry
$PathArray = $FindPath.Replace('/','\').Trim('\').Split('\')

# Each element of FoundPath will be a hash:
# @{
#	'Name'
#	'ProjectID'
# }
$FoundPath = @()

# Get the folders at the top level
$SubFolders = Get-PWFoldersImmediateChildren -Root
ForEach ($fname in $PathArray) {
	# is the current path in the $SubFolder list of names?
	$matchFolder = $SubFolders | Where Name -eq $fname
	if ($null -ne $matchFolder) {
		$FoundPath += @{
			'Name' = $matchFolder.Name
			'ProjectID' = $matchFolder.ProjectID
		}
		$SubFolders = Get-PWFoldersImmediateChildren -FolderID $matchFolder.ProjectID -WarningAction SilentlyContinue
	} else {
		Throw "Folder not found. Path found up to $(($FoundPath.Name) -Join '\')"
	}
}

$FinalPath = ($FoundPath.Name) -Join '\'
$FinalID = $FoundPath[-1].ProjectID

$FolderObj = Get-PWFolders -FolderID $FinalID -JustOne

Write-Host "Found: [Folder ID: $($FinalID)] $($FinalPath)"

This will fail if there are no folders in the root (or whoever runs it doesn't have access to the folders in root). Not gonna fix.

very nice. very "Kernighan and Ritchie"  hah! dated myself there!  I am opting for a function that returns 0 or the found ID...I'm not sure how fast it will be but even if I have to run it over the weekend...it's going to be great!  Thanks Kevin and Brian....still intrigued by Dan's  suggestion ...a CMDLet written in Powershell. This "Exercise" is a good example of the infinite number of "tips, tricks, and even style variations"  that are out there.

Success. The code you provided that I put into a Function is working great...not fast, but "automated", and that works for me. the fact that "Contains" is case insensitive is the key. I'd share the function, but it is nearly the same as the above code. Thanks again!

Yeah, that and storing the matched name rather than the searched name so the final path does come out with the correct casing on the path.

Yeah, that and storing the matched name rather than the searched name so the final path does come out with the correct casing on the path.