It's a plesh - or "tres ples" as the French might say
That was a very good explaination. I understand the program connects to
locations, and if I change the location it won't be able to find them.
I must say, I find the whole namespace vs. file system thing to be
quite problematic, especially in Vista.
Whereas Windows 3.yuk File Manager explored the file system, Windows
Explorer explores the namespace.
The file system comprises drive volumes with letters, and a subtree of
directories below these that contain files and more subdirectories.
The namespace comprises a subtree of namespace objects, many of which
are drive volumes, directories and files, arranged within folders.
The elements of the file system are automatically objects in the
namespace, and the way they are handled and nested will be similar.
Hence the glib explanation that "folder" is just a new name for
"directory". It is at the Newtonian level; it isn't always, once you
get into relativistic territory ;-)
Other namespace objects include computers, networks, and special
behaviours attributed to the contents of single files, collections of
particular files, or particular designated directories.
There's a two-way linkage between special folders such as
"(My )Documents" and the directory to which those behaviors apply.
There may be a forward CLSID link from namespace to location, and
there may be a backward Desktop.ini link from directory back to the
namespace logic. If these should diverge, things get ugly.
My problem with this stuff is where it's ambiguous as to whether you
are operating on the namespace object or the file system location,
especially for Properties that can apply to both.
For example, if I navigate from Users through to a user account and
then to Documents, and I rename Documents, am I renaming the
directory, namespace object, or both?
If I reach the same file system location by navigating from the raw
drive letter of the target location, instead of the desktop Users
folder, does the answer differ?
If I reach the same target by navigating from C:\Users, rather than
desktop Users folder, does the answer differ again?
There may be many ways to change the linkage between a namespace
object like "Documents" and a file system location like
C:\Users\Fred\Documents, but many of these will break things:
- the old location is still treated as the namespace location
- the new location doesn't contain the old namespace's contents
- CLSID target directory has no (or generic) Desktop.ini
- "special" Desktop.ini is left in the old location
- "special" Desktop.ini is now present in more than one location
- duplicate namespace objects appear in Users view
- filenames vs. namespace names get scrambled
Three ways suggest themselves as "OK":
1) Registry search-and-replace
Rigorous, but may leave incorrect back-linkage because the new CLSID
target doesn't contain the correct Desktop.ini, and the old file
system location still does. TweakUI in XP may do this better.
2) Rt-drag, Move
This is the easiest "clean" way to do this in XP, as registry tracks
this move (updating forward CLSID references) and the move also
ensures the correct Desktop.ini in the correct place.
3) Rt-click, Properties, Location, Move, (select location)
New to Vista, and may be safer than (2), but the ambiguity is; which
place, reached by which navigation, should one use to change the
Properties? I'd guess Users desktop icon and thence forward to the
target, to be accessing the namespace object with the least degree of
ambiguity. Next would be C:\Users\etc. that relies on the junction to
the "real" file system location in order to work.
Either way, important rules:
- be careful how you handle "Desktop.ini exists?" (overwrite)
- don't try to rename anything!
I like (3), because this maps to an existing file system location that
can be named before any namespace/file system ambiguity can apply.
In contrast, (2) will drag the old location using the original
directory name, which you then have to change through the
namespace/file system ambiguity that arises because that directory is
already being treated as a "special" namespace object. You have no
opportunity to unambiguously work with the file system directory name,
either before you move the object, or after it has been moved.
This all started becasue my wife wanted to switch computers with me...... LOL
I just avoid the whole user account mess altogether.
Until someone can show me or point me to a URL that will tell me how
to set up ALL locations, UI settings, etc. for the new account
prototype, every new account is going to be born with brain-dead MS
duhfaults that will clash with the way I'd want things set up.
That makes users accounts not only useless to me, but a menace.
--------------- ---- --- -- - - - -
Saws are too hard to use.
Be easier to use!
ave_2, Account type: Standard Account