Borrowing from Windows Explorer in PowerShell part 2: extended properties

When I stated looking at what could be done using explorer objects from PowerShell I “discovered” the extended properties. This vary between operating systems, before Windows 2000 the set was pretty rudimentary, XP and Server 2003 had quite an extensive set of properties and Vista/Server 2008 extends the set still further to 266 items.  You can send a list of the properties to the screen with this command.

[ps]  >  $objShell = New-Object -ComObject Shell.Application
[ps] > $objFolder = $objShell.namespace("C:\")
[ps] > 0..266 | foreach {"{0,3}:{1}"-f $_,$objFolder.getDetailsOf($Null, $_)}
264:Frame rate
265:Frame width
266:Total bitrate

It doesn’t matter which folder you choose at line 2. In line 3 I don’t like using strings with –f in examples but it’s the easiest way to do the output {0,3} is ‘Argument 0 formatted to 3 wide’  - that’s the number and {1] is argument 1, and getDetailsOf $null and a number returns the column name.

I store this in a hash-table in the example below

function Get-ext

{param ($attributes, $Path=(pwd).path)
$objShell = New-Object -ComObject Shell.Application
$objFolder = $objShell.namespace($path)
0..266 | Foreach-object -begin {$Columns=@{} } -process {$Columns.add($objFolder.getDetailsOf($Null, $_),$_)}
foreach ($file in $objFolder.items())  {          $attributes | forEach -begin  {$fileObj = New-Object -TypeName System.Object } `

                               -process {Add-Member -inputObject $fileObj -MemberType NoteProperty -Name $_ `

-Value ($objFolder.GetDetailsOf($file , $Columns[$_]) )}  `
                                -end { $fileObj} }


So the function takes a list of attributes as text. It puts all the attribute names and numbers into a hash table, and for each file it builds an object, the properties are built by saying “for each attribute passed, look up its number and get that attribute for the current file”

I found that there is an extendedProperty() method on the file objects, but that this doesn’t seem to work with all the property names, but asking the Folder object to get the properties does.  SO now I can run a command like this to get the photographic information I want.

Get-ext "name","Title","Tags","f-stop","Exposure Time","ISO Speed" | ft *

Comments (3)
  1. Anonymous says:

    The other day, a friend over in Microsoft Research wanted to figure out how to get out the width and

  2. Martin Stein (alsoknownas[a_t]l1ve[d_o_t]c0m) says:

    James, this is an interesting post. I caught this as a newb, looking for tips on setting up Vista within Hyper-V.

    The other easier way to get to many of these "extended properties" is to open Windows Explorer, right-click on any sorting bar, and select "More." You’ll see a lengthy checklist of the Explorer properties available for display. F-Stop, Exposure Time, and so on can all be displayed without having to run it through PowerShell. The only hitch, of course, is the way that Vista’s folder templates tend to corrupt themselves and become unstable. (If you want me to add a comment about how to fix that problem, I think I have finally found a good solution.)

    Since it’s rare to have this discussion, however, let me offer a potentially powerful direction for the Properties features to evolve for Windows 7. If you know anyone on the Windows Explorer, Windows 7, or PowerShell teams, I’d be grateful if you could pass this along. Here it is:


    For writers and researchers, the major drawback of File Titles is that the user must always drop 2/3 of the most important semantic data. What do I mean by this?

    Think about what happens when you download a document (or any file). You tend to retitle anything important so you can find it and recognize it again later. You develop your own personal system for handling the semantics of the file name, and it’s usually at odds with the way previous users handled the file’s semantics. The file title you choose can usually only designate one of three things: 1) the title of the file as downloaded, or 2) the official plain English file name (if it’s a document), or 3) the semantic meaning that file’s contents have to you — but the Title can’t handle all of these at once. By dropping 2/3 of the relevant information, the user has a much harder time locating vaguely-remembered files, even by searches, when someone else refers you back to them.

    Practical example: A user retitles a found document using constructs most useful to him/her. But when the user comes across that document again in a literature review, the footnotes reference that document by the official title, which the user has decided to discard. It becomes a labor-intensive process to find where the referenced document is stored, and requires an unnecessary resort to a desktop search. Note also: Tags aren’t sufficient to distinguish the document from others. It requires a semantically unique designation.

    Now, there IS a Comments Property under NT6, which in theory should be a place for an alternate Title, but there are serious limitations. If you’ve ever displayed the Comments field, you’ll notice immediately that Comments can’t be added to several file types: HTM and MHT files, for instance. (Think about all the tutorials or online articles you’ve downloaded as MHTs or HTMs for future reference. Wouldn’t it be nice to have that Comments field available for them?)

    The solution has two parts.


    This is the logical equivalent of supplying ALL file types with their own "thumbnail image."

    If we were to refine Windows Explorer, we’d add an additional editing field (like a thumbnail display) in the info margin below the Explorer window. Or, you’d want an additional place to add Properties when right-clicking file Properties (which opens an extended Properties box), or both.

    Ideally, Properties would be able to store several useful pieces of information beyond a single Title: 1) TAGS

    2) ORIGINAL TITLE (The file’s original title as collected)

    3) OFFICIAL TITLE (The file’s official name — which in many cases is very different from the first)

    4) RELEVANCE FIELD 1, RELEVANCE FIELD 2 (The unique semantic description a user wants to add. It can be as verbose as the user wishes. (Relevance 1: "Factors mitigating against Gonzales’ impeachment." Relevance 2: "2007-04-11."))

    One other nice touch would be: If the Explorer window’s lower margin does not show these granular semantic properties fields, then they should be viewable on the TOOLTIP. The semantic info added to the ToolTip could be significantly larger, and cloud the cursor’s movement. Hence, there would have to be a step between hovering over the file and displaying the granular version of the ToolTip: Hence, using WINDOW KEY + CLICK.


    For instance, search by any of the above fields, be it Title, Tags or Relevance.

Comments are closed.

Skip to main content