Classic Shell: Forum

Hello.

I moved de user folder to D:\New\User1 . I did it changhing at (1) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList , "%SystemDrive%\Users"

As a result many icons neither don't appear or don't work anymore. It seems as if Classic Shell don not find the path properly.

With accounts created before that change (1) Classic Shell works ok. I guess Classic Shell need a settings option related with any account in particular.

Thanks.

Classic Shell gets the paths from Windows. It may not be enough to change the user folder in the registry - there is also the location of the start menu, pictures, documents, etc.

Microsoft's documentation here: https://docs.microsoft.com/en-us/window ... sdirectory states:

"We don’t recommend using this setting, except perhaps in a test environment."

"Use this setting to move the user-profile folder (typically %SYSTEMDRIVE%\Users) to another location *during deployment*." So after the OS and programs are installed, moving it seems to be an unsupported scenario.

Instead try this method to move the Users folder before starting to use Windows: http://caspan.com/2012/12/move-the-user ... right-way/ (Move the User Folder To A Separate Drive/Partition (The Right Way)

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

I am a Windows enthusiast and did Classic Shell's testing and usability/UX feedback.

I've been using windows in this way for so long... with out problem... Besides the fact that Microsoft usually say too many things, saying that there is no support for something has no relevance. For example, Microsoft used to say that an annual reinstall was necessary, so what?

The only thing to worry about is when a major update arrives or in case a reinstall is needed... Then, going back or disabling temporarily the relocated user accounts is enough.
b
Summing up: Classic Shell does not take correctly the environement settings, in the contrary, windows's menu does it. I guess it is not so difficult. No windows support was needed. But thank you anyway.

If you consider it is not a bug, it would have been enough just saying it.

Note: Some things about "The right way" according to you:

1.- It is not officially supported either, isn't it? In other words, is as unsopported scenario as what I did, right?
2.- Read: "I can admit that I do not know everything about Windows but normally I have at least heard of most things. Windows Audit Mode was something I had never heard of before so my mind wanted to know what it was." [...] "Please note this has to be done from a fresh install." (oops) "You cannot change the location of the Users folder after you have already started to use Windows already! "(oops) [...] Important issue: "At this point make sure all your drives are set up in their proper order and have their proper drive letters." You'll never know it for sure before installing. (ooops, oops, oops) (See tenforums.com) "At this point you can continue to use Windows just like you normally would but there are a few steps that I like to take to make sure that if for any reason a bad programmer calls the C:\Users folder or C:\ProgramData by its name instead of using system variables (the case of Classic Shell?) then we need to account for this. What I like to do is create 2 Junction point to cover this issue should it ever happen." Finally: This "mklink /j C:\Users D:\Users (where D:\Users is the new location of your users folder)" That used to work fine in Windows 7, not in Windows 10, oops (see tenforum.com)

Summing up: Do not waste your time doing that.

Do not get me wrong, I have only trying to say that (copy and paste from your -unsupported- "right way"): "for any reason a bad programmer calls the C:\Users folder or C:\ProgramData by its name instead of using system variables"?

Note: The only "right way according to what microsoft says" is moving folders such as documents, music, video, etc., one by one. This "right method" leaves AppData completey in its original place -such folder, for example, allocate things like mailbox of outlook or thunderbird, webrowser caches, etc.- Yes, that is a supported scenario, so what?

I will try the next version of Classic Shell in case this is going to be fixed some day.

Best regards and thank you anyway.

Classic Shell uses KNOWNFOLDERIDs, not environment variables. According to MSDN, KNOWNFOLDERIDs supersede both CSIDLs and environment variables and should be used because environment variables have insufficient coverage of Windows special folders. But it is possible that the KNOWNFOLDERIDs do not work properly for many redirected folders (Windows bug, maybe?).

In general, moving the Users folder is not supported very well by the operating system that's why I suggested you a method that's likely to work well with everything - sysprep.

To fix the problem in Classic Shell would require using environment variables everywhere instead of KNOWNFOLDERIDs. Many system/special folders don't have environment variables but only have CSIDLs/KNOWNFOLDERIDs.

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

I am a Windows enthusiast and did Classic Shell's testing and usability/UX feedback.

I do not know, what I do know is that the stock Windows 10 menu works fine, so perhaps there is a bug in Classic Shell? In addition this kind of messages from microsoft like that that used to point out the necessity of an annual reinstall, apart from being not relevant, shows the lack of a feature existing in UNIX-like OSs from already more than 60 years ago?

Anyway, it's a pity, in those systems in which I do not need a partition with users' folders Classic Shell works properly and looks very well.

Thanks for your kind attention.

The stock menu gets to use lots of undocumented/exclusive functions and APIs/methods not all of which are exposed to third party app developers.

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

I am a Windows enthusiast and did Classic Shell's testing and usability/UX feedback.

Yes, I can imagine that dealing with such a terrible thing like %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs and
%SYSTEMDRIVE%\ProgramData\Microsoft\Windows\Start Menu\Programs requires a deeper documentation.

Regards.