cquirke, on your questions:
:>Results can vary depending on exactly how you did this. Did you:
:> - edit registry directly via Regedit?
:> - use a 3rd-party tweaker?
:> - rt-drag the location to E:, Move, and possibly rename it there?
:> - rt-click the namespace object and change the Location property?
:> - other?
I changed the location of the "special folders" (Documents, Music, etc)
using the provided Location tab on the folder's properties, that is included
on Vista. I removed the duplicated by allowing Vista to move the contents
from the old folder to the new one. Vista does the job well.
OK; that's the safest way to do it in my experience, as well. You
should have no inappropriate back-refs from Desktop.ini left in the
old location, and the move should be registry-tracked to update
forward refs (from CLSID to file system) too.
My only quarrel over this customization scheme is what I explained before,
and I think Keith got it. I'll give some more details.
I customize my Downloads folder (that contais all kinds of files) to view
with Details, with the filesize column right next to the name column. I use
this customization as my default customization for all folders except
Documents, Pictures, Videos and Music. I'm glad that when I hit "Apply to all
Folders" on Folder Options, Vista will apply it only to the other folders
that share the same Template. XP applies to all folders indeed, removing my
customizations to the folders I mentioned above.
OK, with you so far...
What I wanted, and Vista doesn't do, is to have the same customization on my
Downloads folder applied to a new folder I create, or to a DVD I insert.
Ah, that's a familiar database concept that the OS writers just don't
seem to get - control over things that don't yet exist.
In database, you often need to lock an item so you can update it,
without another instance (copy) of that item being updated somewhere
else. Typically you have read ops that may or may not lock an item,
and write ops that may or may not release an item, as well as an
explicit unlock operation so that the process can be abandoned.
In order to reduce the critical period (during which an item is
locked), as well as a way to do finer-grained locking (e.g. field
locking rather than record locking), you may do this:
- read-lock item, store in a variable
- release item
- edit item at your own pace
- read-lock item, compare each field with original and edited
- case current = original = edited, release (no write needed)
- case current = original != edited, commit edited
- case current != original = edited, commit current
- case current != original != edited, you have contention:
- commit current
- warn user that changes will be lost
- user can save edited copy locally as "memo" etc.
In the above, "commit" implies also "release lock".
But what if an item doesn't exist, there's nothing to lock, right? I
can just create it and write it, without bothering to check if it's
locked, right? (BTW, a good database language compells you to use
syntax like "read xxxx else if locked do yyyy").
The problem is that an item of same ID may be created while you are
creating yours, so one has to be able to lock items that don't exist.
More to the point, the behaviour applied to items that have not yet
been encountered, has to be controlable. Just as every new user
accound should be born with user-preset behaviors and settings (as
opposed to MS defaults), so every newly-found disk drive etc. should
start off witrh user-defined behaviors.
Given that newly-discovered items arise from outside the system, these
behaviors should be safety-orientated. NOTHING is known, or can be
ASSumed, about a CDR or USB stick that's inserted into the drive, or a
new HD that's discovered in the system! It may not be safe to even
real, let alone write to, or run code from it, etc.
Vista sooooo does not get this... :-(
what would be ideal, wicked, smoking (

) was if Windows ignored any
temporary customization I make on these folders.
It could track customizations as Win9x tracks changes applied to the
Properties of DOS programs on diskettes. Win9x has a subdir called
"PIF" that stores .PIF for such programs, holding their Properties in
them. It's a bit wonky, in that if you set Properties for a file
called BLOB.EXE in the root of disk A:, and you insert a different
disk with a different file that also happens to be called BLOB.EXE and
it's also in the root, then the second prog gets the first prog's
Properties. Too trusting for the 21st century.
For example, I insert a DVD and it shows as Details (like my default
Downloads folder). But some files on this DVD have big names, so I
pull the name column a little bit to view them.
OK...
If I closed Explorer's window and reopened it, Windows would default back to
my Downloads folder customization.
OK. Prolly better than applying the new wider columns to everything
else that uses "no template".
Now, I know Microsoft wants to help us, so Windows memorizes the
DVD folder customization and when I come back the name column
will be as wide as I had set. That would be ok *IF* Windows didn't
lose any customization I made on other folders.
Yyyyeees....
One day (that day already reached me on Vista, unfortunately) I'll
lose my customization on my Downloads folder. So I'll have to set
it all again. When I do that, I'll lose my customizations on the
Documents folder, so I set it again.
That's a good argument to follow the rule that per-instance data
should be stored per-instance, and not in some finite global store.
The .PIF strategy for removable diskettes mentioned above, violates
this rule; though at least the global store used is not capped, it's
still subject to same-name collisions and spoofability.
What I think would be a nice idea was if Windows stored a customization for
each folder I change, no matter how many of them there is.
That's attainable by storing these in the location itself.
But that way of slicing and dicing causes a scalability and
(spoofability, cross-access) risk somewhere else; what if there are a
large number of different user accounts banging away at the same
stuff? Does a USB stick used in 200 PCs accumulate 200 different
settings? What if users and PCs have the same names?
If I modified this folder then Windows would store its proprietary
settings in the registy.
I don't like to treat the registry as an unlimited resource,
especially for holding trivia such as column widths, so I'd like the
ability to disable such tracking. I'm also nervous about the system
taking orders (even trivial orders) from external material.
If I deleted this folder, Windows would delete its customization from
the registry as well. Removable storage could have a session
customization that would be stored as long as the media was
inserted. When the media is removed so are the settings and
the default one is applied when a new media is inserted.
Ah - so you aren't trying to track changes across sessions for the
same removable storage... I thought that was an objective.
------------ ----- ---- --- -- - - - -
The most accurate diagnostic instrument
in medicine is the Retrospectoscope