Stop folder views changing? Please!

[Guest]

Madness beckons...

I know about folder templates, I also know that - bizarrely - the view a
folder presents can depend on how you reached it (though if anyone ... "using
your skill and judgement in 20 words or less" can explain the principles feel
free!, and I know that there is a 5000 (?) limit on the number of
"individual" views that Vista will remember (if only!)

My (increasing) aggravation is that when I change a view on a folder I DO
NOT want the template updated to reflect what I have chosen for this specific
folder! [which is what *seems* to be happening... I keep setting views and
they rarely seem the same when I return. I might just have the memory of a
goldfish but...

what was I saying?

Ah yes... and how can I persuade Vista to remember the views for a drive
which is mapped, so that if the drive is unmounted and then remounted it is
as I left it.

In other words: how do I make a folder look some particular way, stay that
way, and not affect anything else - ever... unless *I* decide otherwise?

Is there perhaps some way to setup desktop.ini to do it?, he asked (perhaps
over) optimistically.

Julian

 

[cquirke (MVP Windows shell/user)]

On Tue, 10 Jul 2007 07:18:02 -0700, Julian

Madness beckons...

Madness takes its toll. Please have the exact change ready

I know about folder templates, I also know that - bizarrely - the view a
folder presents can depend on how you reached it (though if anyone ... "using
your skill and judgement in 20 words or less" can explain the principles feel
free!, and I know that there is a 5000 (?) limit on the number of
"individual" views that Vista will remember (if only!)

Are they still using a global FIFO store to track these things?
Sounds strange, given they dump so much stuff in Desktop.ini already
(and take enough risks there to open up an infection vector).

My (increasing) aggravation is that when I change a view on a folder I DO
NOT want the template updated to reflect what I have chosen for this specific
folder! [which is what *seems* to be happening...

There's a setting to remember views for each folder; I presume that's
on (check that it is, just in case). That would then use the system
you describe, but there may be a complicating factor.

Unlike XP and older, Vista no longer uses a single default template
for undefined views. Instead, it switches between a number of such
templates depending on the content it discovers there.

The question is; does this respect or override any per-folder settings
you have "remembered" for that folder?

I suspect it doesn't. In effect, when you set "this is the view I
want for folder X", it may remember "this is the view I want for
folder X as contents of type Y". If it determines it's now type Z, it
falls back to the default settings for type Z, and I suspect your type
Y preferences for that folder are thrown away.

Normally one can appear to disable this type-sensitivity (which is a
PITA; I don't want some dit to suddenly act as a picture gallery just
because someone dropped a JPG in it) by setting all type templates to
the same view, i.e. List.

But this won't help your pattern (if I have deduced it correctly) if
it's still fussing about whether your contents are type Y or Z (even
if it's merely swapping in templates with the same settings).

This stuff needs to die, or at least be killable. I don't want to
wait for some dumb-ass code to wade through thousands of items to
guess what view to use when I just want the same view anyway, and I do
NOT want the OS groping files, for safety (exploit avoidance) reasons.

Ah yes... and how can I persuade Vista to remember the views for a drive
which is mapped, so that if the drive is unmounted and then remounted it is
as I left it.

Now *that's* another story. Goldfish may remember things like that
for seconds, but Windows won't remember removable disks at all.

There are two good reasons for that:
- there are an unbounded number of removable disks
- removable disks may be changed outside the system

It could use the "cookie" approach to remembering these things, i.e.
by writing a Desktop.ini to the disk (bad idea) or a per-installation
entry to an existing Desktop.ini on the disk (better idea, so that
different systems maintain thier own views of the disk).

That has the advantage of scalability (obeys the "do not store
unbounded data in fixed global locations" dictum) but breaks a safety
rule ("do not initiate risk that the user has not indicated an
intention to take"). OK, we know how useless MS is in terms of that
safety rule, but I wouldn't want to encourage worse behavior.

Mind you, they've been breaking that ruls on diskettes since Win95,
writing tracking labels to the boot record (if the PC's drive is bad
and track 0 on the diskette is trashed, bye-bye data) so perhaps
editing an existing Desktop.ini isn't so horrendous, until you
consider this as an attack vector. That risk is mitigated (limited to
a narrower scope of re-infecting the same PC) if settings are tracked
by installtion so other PCs don't process the changes.

In other words: how do I make a folder look some particular way, stay that
way, and not affect anything else - ever... unless *I* decide otherwise?

I'm not sure if you can. MS often offers functionality that works
only within a certain set of conditions, and when it's "eye candy", I
generally don't fuss much about it.

When it's something like "dual-booting XP And Vista works only if you
don't mind Vista losing all Previous Versions and System Restore
fallback", then I get pissed off.

Is there perhaps some way to setup desktop.ini to do it?, he asked (perhaps
over) optimistically.

Maybe, but I haven't swotted that up - I think you're on the right
track, though. Let's see if there's an "everything you hoped you
wouldn't need to know about Desktop.ini" article in TechNet or MSDN...

Search( Vista Desktop.ini )

Hmm, lots of breakages, or at least forum frowns.

http://help.wugnet.com/vista/Desktop-ini-desktop-ftopict26879.html

Funny how XP never had that problem... I just put them in the corner
and forget about them (visible Desktop,ini on Vista desktop)

http://www.winhelponline.com/articles/169/1/

Interesting, that somewhere it gets processed as a generic .ini file
(maybe in the StartUp folders?) if set to -h -s attributes.

Better search, better results (eventually)...

http://mc-computing.com/WinExplorer/desktop_ini.htm

Meaty, but dates from Win2000 era:

http://msdn.microsoft.com/msdnmag/issues/0300/w2kui/

And now the exploits:

http://secunia.com/advisories/11633/

http://vil.nai.com/vil/content/v_vul23006.htm

That's what happens when you f^&% with the "safety rule".

From a great blog:

http://blogs.msdn.com/oldnewthing/archive/2003/08/27/54715.aspx

A good side track...

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

http://support.microsoft.com/kb/305709/EN-US/

http://support.microsoft.com/kb/156568/EN-US/

Not the pot of gold I was hoping to find, though.

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

Drugs are usually safe. Inject? (Y/n)

 

[Guest]

Oops - didn't get a reply notification on your post and I've been on the
other side of the tank... <g>

That's what I call a fulsome reply - need to take some time to digest it
[not easy at the moment as am recuperating from "something you ate or
drank..." ]

Will get back when I've followed some of the links you provided.

In the meantime... don't suppose there's a way to control folder
presentation by command line is there? I don't mind putting a batch file in
each folder and double-clicking it on open (of course I do, but I'll take
anything I can get).

Thanks

Julian

 

[Guest]

OK... we're back...

Madness takes its toll. Please have the exact change ready

I was short-changed in the sanity dept. to begin with...

Are they still using a global FIFO store to track these things?

AFAIK blah blah MRU bags... there are reg hacks to up the limit but that
just postpones the inevitable; however, would I remember anything that old?
No, the problem is elsewhere...

Yes, remember folder settings is on, BUT

Unlike XP and older, Vista no longer uses a single default template
for undefined views. Instead, it switches between a number of such
templates depending on the content it discovers there.

One solution could be Kritsan Kenney's
http://www.windows-now.com/blogs/km...-disable-automatic-folder-type-discovery.aspx

The question is; does this respect or override any per-folder settings
you have "remembered" for that folder?

I suspect it doesn't. In effect, when you set "this is the view I
want for folder X", it may remember "this is the view I want for
folder X as contents of type Y". If it determines it's now type Z, it
falls back to the default settings for type Z, and I suspect your type
Y preferences for that folder are thrown away.

I think you are right, which makes the "Remember folder settings" at very
least misleading and probably a downright lie; at best it remembers how
things were *if nothing has changed since you closed the folder* - tough luck
if you have saved a picture from the web into a document folder...

Normally one can appear to disable this type-sensitivity (which is a
PITA; I don't want some dit to suddenly act as a picture gallery just
because someone dropped a JPG in it) by setting all type templates to
the same view, i.e. List.

(PITA? dit?) true, but not not the best way of working!

This stuff needs to die, or at least be killable.

Hmmm... public accountability... WHO is responsible for this absurd way of
doing things? Public humiliation is in order (it attracts a shorter sentence
than homicide)

Now *that's* another story. Goldfish may remember things like that
for seconds, but Windows won't remember removable disks at all.

I was afraid of that... but what, in principle, is the difference between
network storage - which AFAIK allows each user to have their own view of a
folder - and "removable storage"; whatever mechanism used for the former
should surely be acceptable for the latter.

There are two good reasons for that:
- there are an unbounded number of removable disks

I don't understand why that would be an issue with a "cookie" approach

- removable disks may be changed outside the system

I don't understand why that would be an issue either if the "cookie" is tied
somehow to the computer Id/user...

I read all the links - exploits and risks etc. understood - but the
(rhetorical) question is still: a view is a set of parameters, there is no
need for executables or obscure CLSIDs... I don't see that there *has* to be
a risk - if properly implemented.

I'm not sure if you can. MS often offers functionality that works
only within a certain set of conditions, and when it's "eye candy", I
generally don't fuss much about it.

<sigh> for me, "eye candy" is more than that - I am forever delving for info
across a wide range of locations... and the new Search "functionality" is not
helpful (e.g. can't tag all image file types - result: either I rename the
files or I look for them by appearance)

When it's something like "dual-booting XP And Vista works only if you
don't mind Vista losing all Previous Versions and System Restore
fallback", then I get pissed off.

Indeed! As would I... which I why I shall not be doing any such thing

Maybe, but I haven't swotted that up

If you do feel like swotting, be my guest! I tried some old XP dsktop.ini
hacks for other purposes and they didn't work; I've been wondering about
scripting (one script per folder... I set up my view, run the script, it uses
get CurrentViewMode, writes a tiny text file and I can run a "set" script to
restore my view...

However, whilst I can program, I have neither the time not the inclination
to learn a new environment to fix something that shouldn't be broke. I've
tried looking for scripts that would do this for me to no avail so far... not

Not the pot of gold I was hoping to find, though.

Ah.... that'll be a Microsoft rainbow then! Actually, first you need to grab
hold of the leprechaun and not look away until he has told you where it is...

So... if I could only find out the WHO referred to above...

Thanks for you thoughts - if you do find out anything, I suspect I'm not the
only one who would be rather pleased!

Julian

 

[cquirke (MVP Windows shell/user)]

On Thu, 26 Jul 2007 03:10:01 -0700, Julian

AFAIK blah blah MRU bags... there are reg hacks to up the limit but that
just postpones the inevitable; however, would I remember anything that old?

IOW, I think they are.

No, the problem is elsewhere...

I've since written up this issue as a "Vista Wish" here...

http://cquirke.spaces.live.com/blog/cns!C7DAB1E724AB8C23!287.entry

....as well as submitting this, with another 35-odd, to MS. Full list:

http://cquirke.spaces.live.com/blog/cns!C7DAB1E724AB8C23!336.entry

This thread inspired me to cover this topic, BTW ;-)

One solution could be Kritsan Kenney's
http://www.windows-now.com/blogs/km...-disable-automatic-folder-type-discovery.aspx

Good article, frustratingly light on background details, tho (as
commented, comment prolly in the moderation queue)

I think you are right, ... at best it remembers how things were
*if nothing has changed since you closed the folder* - tough luck
if you have saved a picture from the web into a document folder...
Exactlty.


(PITA? dit?) true, but not not the best way of working!

Pain In The Adenoids, and typo for "dir"

I was afraid of that... but what, in principle, is the difference between
network storage - which AFAIK allows each user to have their own view of a
folder - and "removable storage"; whatever mechanism used for the former
should surely be acceptable for the latter.

Scalability, most likely. In fact, persistance of long-gone network
items in "My Network Places" can be a nuisance. As you say, there's
much in common, but perhaps one expects the network shares one sees to
be more likely to be seen again.

I don't understand why that would be an issue with a "cookie" approach

Do I want my removable storage to be automatically written to by every
PC I use it on? Would my answer change if the medium was failing or
otherwise at risk? IMO, safest is if the PC does not initiate any
access (or especially, writes) to newly-discovered storage. See...

http://cquirke.spaces.live.com/blog/cns!C7DAB1E724AB8C23!289.entry

I don't understand why that would be an issue either if the "cookie" is tied
somehow to the computer Id/user...

Prolly the best way to do that would be a series of entries in a
Desktop.ini [section] that identify installation and user account
name. But is there a privacy impact to harvesting this info? Are
there risks associated with asserting particular view settings that
will come into effect when the storage is seen by your PC again?

IOW, a malware could edit that Desktop.ini and change all existing
entries to invoke itself when the storage is seen again by those
systems, and use that as a way to attack or infect them.

That depends on how buttoned-down the viewing interface is, but as we
already have Desktop.ini-mediated exploits...

I read all the links - exploits and risks etc. understood - but the
(rhetorical) question is still: a view is a set of parameters, there is no
need for executables or obscure CLSIDs... I don't see that there *has* to be
a risk - if properly implemented.

....makes me think it is not properly implimented. Remember "View As
Web Page"? Where do you think that's gone - died the death it
deserves, or rolled into the standard UI with no setting to kill it?

If you do feel like swotting, be my guest! I tried some old XP dsktop.ini
hacks for other purposes and they didn't work; I've been wondering about
scripting (one script per folder... I set up my view, run the script, it uses
get CurrentViewMode, writes a tiny text file and I can run a "set" script to
restore my view...

Any solution that works by enticing arbitrary PCs to run scripts on
the removable disk, would be a severe safety risk IMO.

So... if I could only find out the WHO referred to above...

Thanks for you thoughts - if you do find out anything, I suspect I'm not the
only one who would be rather pleased!

Maybe drop a Q in the comments at "The Old New Thing"...

http://blogs.msdn.com/oldnewthing/

....or other shell team blog?

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

When Occam's Razor meets the Halting Problem,
the Halting Problem wins

 

[Guest]

Hi again belatedly

Thanks for taking the thoughts on board and making a wish!

I think I tried the oldnewthing but new posts were disabled

The removable storage issue hadn't occurred to me, but the isgnificance was
brought home immediately by a 1 month old Lexar JumpDrive that took exception
to the idea of data integrity...

I appreciate all that you say about security but I would still like a script
("Julian's View.vbs"?) that *I* could run manually to set a folder view (no
automatic running)... that would be just one double-click instead of 5 mins
fiddling per folder and UAC should stop any malware (assuming it could get
in) doing anything with my script other than changing view (which UAC should
not be bothered about... I hope)

I thought about having a go myself but I don't know Windows scripting of any
flavour and the the thought of wriggling my way through the appropriate
object model sent shivers down my spine... so I guess I shall just have to go
without.

Are the folder view aggravations the sort of thing that SP1 will address
(question expecting the answer no)...? No need to answer, just wishing
rhetorically

Julian

http://berossus.blogspot.com/

PS Did read the death threat at the oldnewthing... I may get annoyed but
that was a little disproportionate! Rotten eggs and kimchi would be my
preferred form of assault <g> But Some Stuff does indeed deserve to die - I
would be very grateful if someone would put Explorer Views out of my misery.