Re: Default view of folders reverts back to previous settings.

K

Keith Miller MVP

"cquirke (MVP Windows shell/user)" <[email protected]> wrote in
message news:[email protected]
>
> To me, these frills are almost more hassle than they are worth. I
> want List view everywhere, with a minimum of unsolicited content
> groping, but that is at odds with the direction of Vista's quest to
> "make it easier" and be more effective/powerful.
>


Set the list view for a folder that's using the 'All Items' template, then
use 'Apply to Folders'. Then override content-sniffing with my 'AllFolders'
regedit:

Copy the text between the lines below into notepad & save as a .reg file.
Watch out for line wrap -- [HKEY_CURRENT_USER\...\Shell] is all one line,
there is a space between 'Local' and 'Settings'.

--------------------------------------------------
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Classes\Local
Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\Shell]
"FolderType"="NotSpecified"

--------------------------------------------------

Merging the .reg file will set the 'All Items' template for any folders that
don't currently have a view saved with a different template. You can clear
all saved views by deleting the

"HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags"

key BEFORE merging the .reg file. If any folders open with a different
template after clearing the 'Bags' key & merging the .reg file, they most
likely have a template specified via their desktop.ini file.
 

My Computer

K

Keith Miller MVP

"cquirke (MVP Windows shell/user)" <[email protected]> wrote in
message news:[email protected]
> On Sat, 31 Mar 2007 10:20:07 -0500, "Keith Miller MVP"
>>"cquirke (MVP Windows shell/user)"

>
>>> I want List view everywhere, with a minimum of content groping

>
>>Set the list view for a folder that's using the 'All Items' template, then
>>use 'Apply to Folders'. Then override content-sniffing with my
>>'AllFolders'

>
>>--------------------------------------------------
>>Windows Registry Editor Version 5.00
>>
>>[HKEY_CURRENT_USER\Software\Classes\Local
>>Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\Shell]
>>"FolderType"="NotSpecified"
>>
>>--------------------------------------------------

>
>>Merging the .reg file will set the 'All Items' template for any folders
>>that
>>don't currently have a view saved with a different template. You can
>>clear
>>all saved views by deleting the

>
>>"HKCU\Software\Classes\Local
>>Settings\Software\Microsoft\Windows\Shell\Bags"

>
>>key BEFORE merging the .reg file. If any folders open with a different
>>template after clearing the 'Bags' key & merging the .reg file, they most
>>likely have a template specified via their desktop.ini file.

>
> Ahh... thanks! I'm a bit confused on the details of how behaviors are
> linked to locations; is it all from file system to behaviors via
> Desktop.ini, or all forward from CLSIDs to locations, or a combination
> of the two? Because it seems to come unstuck easily...
>

View behaviors, right?

First & foremost, saved views are dependent on the namespace path, which is
graphically represented in the folder tree in Explorer.

'Desktop\UserName'

can save a view distinct from

'Desktop\Computer\C:\Users\UserName'

If you take a look at:

'HKCU\Software\Classes\Local
Settings\Software\Microsoft\Windows\Shell\BagMRU'

which is the index to saved views, you'll see that is a tree structure, with
BagMRU corresponding to the Desktop and each numbered subkey representing a
subfolder. If a key has a 'Nodeslot' value, that is the Bag number for the
saved view for that folder.

According to http://msdn2.microsoft.com/en-us/library/ms647825.aspx

"By default, if SHGVSPB_INHERIT is not specified and a property bag cannot
be found for the specified folder, the system searches for identically named
property bags in other locations that may be able to provide default values.
For example, the system searches in the ancestors of the folder to see if
any of them provide a SHGVSPB_INHERIT property bag. Other places the system
searches are in the user defaults and the global defaults.

So, when a folder is opened, Explorer first looks for a saved view for that
particular folder. If that does not exist, Explorer works its way back up
the namespace path to see if any of the parents' views have an 'Inherit'
subkey (this is how 'Also apply this template to all subfolders' works). If
there are none, then Explorer checks for 'AllFolders'. If 'AllFolders'
exists and specifies a template, that template is assigned. If no template
is specified or 'AllFolders' doesn't exist, then content sniffing kicks in.
Once Explorer has determined content type, it will look for the template
UUID under 'AllFolders' and then under:
'HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Streams\Defaults'
If those don't exist, then the settings found under:
'HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\FolderTypes'
will be used.


--
Good Luck,

Keith
Microsoft MVP [Windows XP Shell/User]
 

My Computer

C

cquirke (MVP Windows shell/user)

On Mon, 2 Apr 2007 10:46:13 -0500, "Keith Miller MVP"
>"cquirke (MVP Windows shell/user)"


I'm going to read this reaaaly slowly - great content ahead!

>> Ahh... thanks! I'm a bit confused on the details of how behaviors are
>> linked to locations; is it all from file system to behaviors via
>> Desktop.ini, or all forward from CLSIDs to locations, or a combination
>> of the two? Because it seems to come unstuck easily...
>>

>View behaviors, right?


Yep!

>First & foremost, saved views are dependent on the namespace path, which is
>graphically represented in the folder tree in Explorer.


>'Desktop\UserName'


....what I refer to as the "namespace object"

> can save a view distinct from


>'Desktop\Computer\C:\Users\UserName'


....what I refer to as the "file system location"

In XP, the difference was clear - the one would show the object name
and the other would show the directory name. The contents may or may
not look different and the icon would usually look the same (giving
you feedback that that particular location was "special").

In Vista, things get murky because object (rather than directory)
names are often appended at the end of the file system path.

>If you take a look at:


>'HKCU\Software\Classes\Local
>Settings\Software\Microsoft\Windows\Shell\BagMRU'


>which is the index to saved views, you'll see that is a tree structure, with
>BagMRU corresponding to the Desktop and each numbered subkey representing a
>subfolder. If a key has a 'Nodeslot' value, that is the Bag number for the
>saved view for that folder.


I can't find that in XP SP2 but similar in
HKLM\Software\Microsoft\Windows\Shell etc.

>According to http://msdn2.microsoft.com/en-us/library/ms647825.aspx


>...when a folder is opened, Explorer first looks for a saved view for that
>particular folder. If that does not exist, Explorer works its way back up
>the namespace path to see if any of the parents' views have an 'Inherit'
>subkey (this is how 'Also apply this template to all subfolders' works). If
>there are none, then Explorer checks for 'AllFolders'. If 'AllFolders'
>exists and specifies a template, that template is assigned. If no template
>is specified or 'AllFolders' doesn't exist, then content sniffing kicks in.


Tell me more about these templates... in the IE4 era, we had
Desktop.ini pointing to *.htt files that allowed HTML scripting to be
bound to locations, in ways amenable to malware use - so that every
full-shared location was potentially a malware drop-and-run point.

Win98/SE/ME had the ability to kill "View as Web Page" to curb this
risk; a setting that no longer appears in XP and Vista.

Are these newer OSs cluefull enough to suppress "Web Page" scripts, or
dumb enough to integrate these with no option to disable them?

Are there other opportunities to edit a Desktop.ini so as to invoke
code; say, via a CLSID? Let's leave aside pointing to a "specially
crafted" .ICO using the .ANI exploit for now.

>Once Explorer has determined content type, it will look for the template
>UUID under 'AllFolders' and then under:
>'HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Streams\Defaults'
>If those don't exist, then the settings found under:
>'HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\FolderTypes'
>will be used.


OK. Is this "CU before LM" order pervasive across all file
associations etc. as lumped together in the HKCR view?

Thanks for a great article, BTW :-)



>------------ ----- ---- --- -- - - - -

The most accurate diagnostic instrument
in medicine is the Retrospectoscope
>------------ ----- ---- --- -- - - - -
 

My Computer

K

Keith Miller MVP

"cquirke (MVP Windows shell/user)" <[email protected]> wrote in
message news:[email protected]
> On Mon, 2 Apr 2007 10:46:13 -0500, "Keith Miller MVP"
>>"cquirke (MVP Windows shell/user)"

>
> I'm going to read this reaaaly slowly - great content ahead!
>
>>> Ahh... thanks! I'm a bit confused on the details of how behaviors are
>>> linked to locations; is it all from file system to behaviors via
>>> Desktop.ini, or all forward from CLSIDs to locations, or a combination
>>> of the two? Because it seems to come unstuck easily...
>>>

>>View behaviors, right?

>
> Yep!
>
>>First & foremost, saved views are dependent on the namespace path, which
>>is
>>graphically represented in the folder tree in Explorer.

>
>>'Desktop\UserName'

>
> ...what I refer to as the "namespace object"
>
>> can save a view distinct from

>
>>'Desktop\Computer\C:\Users\UserName'

>
> ...what I refer to as the "file system location"
>
> In XP, the difference was clear - the one would show the object name
> and the other would show the directory name. The contents may or may
> not look different and the icon would usually look the same (giving
> you feedback that that particular location was "special").
>
> In Vista, things get murky because object (rather than directory)
> names are often appended at the end of the file system path.
>
>>If you take a look at:

>
>>'HKCU\Software\Classes\Local
>>Settings\Software\Microsoft\Windows\Shell\BagMRU'

>
>>which is the index to saved views, you'll see that is a tree structure,
>>with
>>BagMRU corresponding to the Desktop and each numbered subkey representing
>>a
>>subfolder. If a key has a 'Nodeslot' value, that is the Bag number for
>>the
>>saved view for that folder.

>
> I can't find that in XP SP2 but similar in
> HKLM\Software\Microsoft\Windows\Shell etc.


In XP, the equivalent key is:

"HKCU\Software\Microsoft\Windows\ShellNoRoam\BagMRU"

>
>>According to http://msdn2.microsoft.com/en-us/library/ms647825.aspx

>
>>...when a folder is opened, Explorer first looks for a saved view for that
>>particular folder. If that does not exist, Explorer works its way back
>>up
>>the namespace path to see if any of the parents' views have an 'Inherit'
>>subkey (this is how 'Also apply this template to all subfolders' works).
>>If
>>there are none, then Explorer checks for 'AllFolders'. If 'AllFolders'
>>exists and specifies a template, that template is assigned. If no
>>template
>>is specified or 'AllFolders' doesn't exist, then content sniffing kicks
>>in.

>
> Tell me more about these templates... in the IE4 era, we had
> Desktop.ini pointing to *.htt files that allowed HTML scripting to be
> bound to locations, in ways amenable to malware use - so that every
> full-shared location was potentially a malware drop-and-run point.
>


When I say template, I'm refering to the choices that appear on the
'Customize' tab: 'All Items', 'Documents', etc. These govern the tasks
offered, default icon style, & default columns selected, etc. Nothing so
advanced as retaining HTML malware :)

> Win98/SE/ME had the ability to kill "View as Web Page" to curb this
> risk; a setting that no longer appears in XP and Vista.
>
> Are these newer OSs cluefull enough to suppress "Web Page" scripts, or
> dumb enough to integrate these with no option to disable them?


They're suppressed by default in XP, but could be activated:

http://support.microsoft.com/kb/819028/

I doubt they work at all in Vista, but I never really played with them, even
in XP.


> Are there other opportunities to edit a Desktop.ini so as to invoke
> code; say, via a CLSID? Let's leave aside pointing to a "specially
> crafted" .ICO using the .ANI exploit for now.


There was under XP, but it was disabled by default in one of the updates,
but can reactived via a policy setting. Haven't checked under Vista -- I
assume it's at least disabled by default if not completely unavailable.


>>Once Explorer has determined content type, it will look for the template
>>UUID under 'AllFolders' and then under:
>>'HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Streams\Defaults'
>>If those don't exist, then the settings found under:
>>'HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\FolderTypes'
>>will be used.

>
> OK. Is this "CU before LM" order pervasive across all file
> associations etc. as lumped together in the HKCR view?


Only items under 'HKCU\Software\Classes' & 'HKLM\SOFTWARE\Classes' merge to
form the HKCR key. User-specific takes precedence over machine-wide, but
'Defaults' uses a Binary data structure to hold the view settings and holds
more specific detail, such as column width, whereas 'FolderTypes' uses
individual values for Icon Style, default columns, etc -- there're not
identical keys/values like:

'HKLM\...\Explorer\HideDesktopIcons'
&
'HKCU\...\Explorer\HideDesktopIcons'

>
> Thanks for a great article, BTW :-)
>


You're welcome! :-)


--
Good Luck,

Keith
Microsoft MVP [Windows XP Shell/User]
 

My Computer

C

cquirke (MVP Windows shell/user)

On Wed, 4 Apr 2007 02:11:55 -0500, "Keith Miller MVP"
>"cquirke (MVP Windows shell/user)" wrote
>> On Mon, 2 Apr 2007 10:46:13 -0500, "Keith Miller MVP"
>>>"cquirke (MVP Windows shell/user)"


>>>'HKCU\Software\Classes\Local
>>>Settings\Software\Microsoft\Windows\Shell\BagMRU'


>> I can't find that in XP SP2 but similar in
>> HKLM\Software\Microsoft\Windows\Shell etc.

>
>In XP, the equivalent key is:
>
>"HKCU\Software\Microsoft\Windows\ShellNoRoam\BagMRU"


OK, thanks; got it...

>> Tell me more about these templates... in the IE4 era, we had
>> Desktop.ini pointing to *.htt files that allowed HTML scripting to be
>> bound to locations, in ways amenable to malware use - so that every
>> full-shared location was potentially a malware drop-and-run point.


>When I say template, I'm refering to the choices that appear on the
>'Customize' tab: 'All Items', 'Documents', etc. These govern the tasks
>offered, default icon style, & default columns selected, etc. Nothing so
>advanced as retaining HTML malware :)


That's good. WinME let you slam the door on "View As Web Page", but
XP and Vista no longer have such an option, and yet have suspiciously
detailed and lavish possible views. It wasn't at all clear wether
this was using Folder.htt etc. but with no safety catch anymore.

>> Are these newer OSs cluefull enough to suppress "Web Page" scripts, or
>> dumb enough to integrate these with no option to disable them?

>
>They're suppressed by default in XP, but could be activated:
>
>http://support.microsoft.com/kb/819028/


OK, good that they're suppressd by default.

>> Are there other opportunities to edit a Desktop.ini so as to invoke
>> code; say, via a CLSID? Let's leave aside pointing to a "specially
>> crafted" .ICO using the .ANI exploit for now.


>There was under XP, but it was disabled by default in one of the updates,
>but can reactived via a policy setting. Haven't checked under Vista -- I
>assume it's at least disabled by default if not completely unavailable.


OK, that's good.



>------------ ----- ---- --- -- - - - -

Our senses are our UI to reality
>------------ ----- ---- --- -- - - - -
 

My Computer

Top