How to list folder properties using Powershell

I have this bit of Powershell code that will list all the folder property friendly names, but I can't figure out how to get a list with the associated system properties.

Code:

$Folder = (New-Object -ComObject Shell.Application).NameSpace("C:\")
0..400 | ForEach {
  If ($DataValue = $Folder.GetDetailsOf($null, $_)) {
    Write-Output "$DataValue"
  }
}

The code above outputs a list like this:

Code:

Name
Size
Item type
Type
Date modified
Date created
Date accessed
Attributes
Owner
Folder path
...

I want to get a list like this:

Code:

System.ItemNameDisplay, Name
System.Size, Size
System.ItemType, Item type
System.ItemTypeText, Type
System.DateModified, Date modified
System.DateCreated, Date created
System.DateAccessed, Date accessed
System.FileAttributes, Attributes
System.FileOwner, Owner
System.ItemFolderPathDisplay, Folder path
...

Any help would be much appreciated!

Apparently shell.application cannot return the canonical property names. It looks like propsys.dll will need to be used. Some clues here: https://devblogs.microsoft.com/oldne...429-00/?p=4523 and here: How to get the length (duration) of a media File in C# on Windows 7 - CodeProject

Unfortunately, it's a bit beyond my skills to leverage any of that to use with Powershell. @KeithM Does this even look like I'm on the right track?

Cheat!!! Property System Viewer For Windows 10 / 8 / 7 / Vista

The Windows Property System - CodeProject

KeithM said:

Cheat!!! Property System Viewer For Windows 10 / 8 / 7 / Vista

The Windows Property System - CodeProject

LOL. I'm already using Nirsoft's PropertySystemView as a workaround. What makes it a bit tricky is that it has no option that will output the 300ish folder view properties, so I have to dump all 1600ish properties and then match them against the output from that Powershell code above. That gets interesting because "Status" appears three times (on en-US) from the Powershell code and "Status" appears 8 times in the PropertySystemView output:

System.Devices.IsSoftwareInstalling,Status
System.Devices.NotWorkingProperly,Status
System.Devices.Status,Status
System.Devices.Status1,Status
System.Devices.Status2,Status
System.LOGON.Status,Status
System.Status,Status
System.StorageProviderUIStatus,Status

Fortunately, PropertySystemView has other fields that allow me to narrow down the correct match. The most important is the one that indicates if the property is "readable" or not. So, I have a working solution, but it would be nice if I could just get those 300ish properties directly dumped with the display name because I can't be certain that the matching algorithm will work perfectly in all languages. So far, it's been correct, but there are a lot of languages! Below is some sample output in German and Japanese. Note that I swapped the canonical name and display name to make it easier to sort (and I dropped "System." to save space). "Name" in German is "Name", so that's not a mistake.

Name,ItemNameDisplay
Änderungsdatum,DateModified
Erstelldatum,DateCreated
Letzter Zugriff,DateAccessed
Größe,Size
Typ,ItemTypeText
Elementtyp,ItemType
Erkannter Typ,PerceivedType
Inhaltstyp,ContentType
Art,Kind
Dateierweiterung,FileExtension
Besitzer,FileOwner
Attribute,FileAttributes
Ordnerpfad,ItemFolderPathDisplay
Ordner,ItemFolderPathDisplayNarrow
Pfad,ItemPathDisplay
Ordnername,ItemFolderNameDisplay
Kategorien,Category
Relevanz,Search.Rank

名前,ItemNameDisplay
更新日時,DateModified
作成日時,DateCreated
アクセス日時,DateAccessed
サイズ,Size
種類,ItemTypeText
項目の種類,ItemType
認識された種類,PerceivedType
内容の種類,ContentType
分類,Kind
ファイル拡張子,FileExtension
所有者,FileOwner
属性,FileAttributes
フォルダーのパス,ItemFolderPathDisplay
フォルダー,ItemFolderPathDisplayNarrow
パス,ItemPathDisplay
フォルダー名,ItemFolderNameDisplay
分類項目,Category
関連度,Search.Rank

So, I tried to compile that little C++ program: https://devblogs.microsoft.com/oldne...429-00/?p=4523

It's tiny. How hard could it be?

First try...

Code:

propdisp.cpp(10): error C2065: 'CCoInitialize': undeclared identifier
propdisp.cpp(10): error C2146: syntax error: missing ';' before identifier 'init'
propdisp.cpp(10): error C2065: 'init': undeclared identifier
propdisp.cpp(11): error C2065: 'init': undeclared identifier
propdisp.cpp(17): error C3872: '0x9d': this character is not allowed in an identifier
propdisp.cpp(17): error C2065: 'L�': undeclared identifier
propdisp.cpp(17): error C2017: illegal escape sequence
propdisp.cpp(17): error C2065: 'ls': undeclared identifier
propdisp.cpp(17): error C2146: syntax error: missing ')' before identifier 'n�'
propdisp.cpp(17): error C2146: syntax error: missing ';' before identifier 'n�'
propdisp.cpp(17): error C2065: 'n�': undeclared identifier
propdisp.cpp(17): error C2059: syntax error: ')'

Oh yeah, I almost forgot... All of Microsoft's code example's get borked when they post them to their website because the ' and " characters get converted to pretty, curvy single and double quotes. Who was the genius responsible for that move and why has it been that way for, what, decades?

OK... I correct the ” and ” to " and try again...

Code:

propdisp.cpp
propdisp.cpp(10): error C2065: 'CCoInitialize': undeclared identifier
propdisp.cpp(10): error C2146: syntax error: missing ';' before identifier 'init'
propdisp.cpp(10): error C2065: 'init': undeclared identifier
propdisp.cpp(11): error C2065: 'init': undeclared identifier

Grrrrr. Why does this have to be so d**n hard...

So, I look at the web page again and notice that "CCoInitialize" is a link! Following the link I find the extra code and paste that in.

Try again...

Code:

propdisp.cpp
Microsoft (R) Incremental Linker Version 14.28.29915.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:propdisp.exe
propdisp.obj
propdisp.obj : error LNK2019: unresolved external symbol __imp__PSGetPropertyDescriptionByName@12 referenced in function _wmain
propdisp.exe : fatal error LNK1120: 1 unresolved externals

Grrrrrrrrr. Why does this have to be so f***ing hard...

I recall trying to compile a small C++ program about 20 years ago and it went pretty much the same. I think I better stick to scripting.

LesFerch said:

LOL. I'm already using Nirsoft's PropertySystemView as a workaround. What makes it a bit tricky is that it has no option that will output the 300ish folder view properties, so I have to dump all 1600ish properties and then match them against the output from that Powershell code above. That gets interesting because "Status" appears three times (on en-US) from the Powershell code and "Status" appears 8 times in the PropertySystemView output:

...

Fortunately, PropertySystemView has other fields that allow me to narrow down the correct match. The most important is the one that indicates if the property is "readable" or not. So, I have a working solution, but it would be nice if I could just get those 300ish properties directly dumped with the display name because I can't be certain that the matching algorithm will work perfectly in all languages. So far, it's been correct, but there are a lot of languages! Below is some sample output in German and Japanese. Note that I swapped the canonical name and display name to make it easier to sort (and I dropped "System." to save space). "Name" in German is "Name", so that's not a mistake.

Since you're rounding up the properties from Shell.Application, I think you should be able to create a list of only those canonical names associated with a column header by rounding up the data from the ColumnList values in the various TopView definitions under HKLM\...\FolderTypes:

Code:

$FT = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderTypes'

gci $FT -s | ? PSChildName -like "{*}" |
    ? Property -contains 'ColumnList' |
        Get-ItemPropertyValue -Name ColumnList | %{
            $_ -replace ( 'prop\:0|\(\d+\)' , '' ) -replace ( ';0|;1|;2' , ';' ) -split ';'
} | select -Unique | Sort

Code:

PS C:\...\nl-NL>$FT = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderTypes'
>>
>> gci $FT -s | ? PSChildName -like "{*}" |
>>     ? Property -contains 'ColumnList' |
>>         Get-ItemPropertyValue -Name ColumnList | %{
>>             $_ -replace ( 'prop\:0|\(\d+\)' , '' ) -replace ( ';0|;1|;2' , ';' ) -split ';'
>> } | select -Unique | Sort
System.Audio.EncodingBitrate
System.Author
System.Category
System.Comment
System.Contact.BusinessTelephone
System.Contact.EmailAddress
System.Contact.EmailName
System.Contact.FileAsName
System.Contact.FirstName
System.Contact.FullName
System.Contact.Gender
System.Contact.GivenName
System.Contact.HomeTelephone
System.Contact.LastName
System.Contact.MiddleName
System.DateCreated
System.DateImported
System.DateModified
System.DRM.IsProtected
System.FileCount
System.FlagStatus
System.GPS.LatitudeDecimal
System.GPS.LongitudeDecimal
System.Home.SortOrder
System.Image.Copyright
System.Image.Dimensions
System.Image.HorizontalSize
System.Image.VerticalSize
System.Importance
System.ItemDate
System.ItemFolderPathDisplay
System.ItemFolderPathDisplayNarrow
System.ItemNameDisplay
System.ItemTypeText
System.Keywords
System.Kind
System.Media.DateEncoded
System.Media.Duration
System.Media.Producer
System.Media.Publisher
System.Media.SubTitle
System.Media.ThumbnailLargePath
System.Media.ThumbnailSmallPath
System.Media.Writer
System.Media.Year
System.Message.DateReceived
System.Message.FromName
System.Message.HasAttachments
System.Music.AlbumArtist
System.Music.AlbumTitle
System.Music.Artist
System.Music.Composer
System.Music.Conductor
System.Music.DisplayArtist
System.Music.Genre
System.Music.TrackNumber
System.Photo.CameraManufacturer
System.Photo.CameraModel
System.Photo.DateTaken
System.Photo.ExposureTime
System.Photo.FNumber
System.Photo.FocalLength
System.Photo.ISOSpeed
System.Photo.MeteringMode
System.Photo.Orientation
System.Photo.PeopleNames
System.Rating
System.Search.Rank
System.Size
System.StorageProviderId
System.StorageProviderUIStatus
System.ThumbnailCacheId
System.Title
System.Video.Director
System.Video.FrameHeight
System.Video.FrameWidth
System.Video.Orientation
System.Video.TotalBitrate
PS C:\...\nl-NL>

Hopefully, that will eliminate or at least reduce the ambiguity in matching labels to canonical names.

---

As for the multiple-language issue, do you have access to the associated propsys.dll.mui files, you could build a hashtable of string resource IDs and labels, and (I'm pretty sure) the resource IDs for each will be that same across language versions.

---

But the above are just workarounds. Did you look at the CodeProject link I posted? It's a more recent, seeminly complete, way to access the Property System via C#. So ultimately, we both need to bite the bullet & delve into C# to get a handle on that code. With that understanding, I would hope it would be possible to create Add-Type definitions that would allow access the Property System from PowerShell.

@KeithM We get 308 properties from shell.application, which match the right-click, "More" list in Explorer. The FolderTypes key unfortunately has only about 78 of those properties listed.

Using the output from PropertySystemView, I'm currently getting a perfect match of the 308 properties to the display names, using the "readable" field as a secondary check and using elimination to ensure I don't pick the same property twice for a duplicate display name. I've tested on a few different languages now with no issues.

It would be nice to leverage the code from that CodeProject link, but my kung fu isn't good enough to make that happen, so I'll have to be content with my hacked up solution. Fortunately, I don't need this to work in real time. I'm creating the tables ahead of time and saving them as Unicode text files in a "Language" folder. I suppose the data could be used in real time with the right code. Future enhancement, I suppose...