2

all

I am trying to move AppData\Local, AppData\Roaming, and AppData\LocalLow to my D: drive.

I know this is ill-advised by Microsoft, but if developers would be inclined to NOT store all there data in these directories I'd be fine. Any-how, I have GIGs of data stored there and my C: drive is only supposed to house my OS.

I have created a new administrative user, copied all the contents of each folder into a respective folder on another drive. I then use the command mklink /j C:\Users\my-user\AppData\<folder> D:\Users\my-user\AppData\<folder> to make a junction for each folder respectively (as I cannot seem to do the whole AppData directory. LocalLow and Roaming seem to each do fine. But I cannot seem to move Local without completely messing up my taskbar/start menu (e.g. it will not open the start menu, search menu, cortona. I can't right click icons to see options, I can't open notifications bar, volume menu, or network menu. Curiously though, I can open the processes menu so there's that).

I have found a ps command to install the start menu host and cortana, but can't seem to find all the other necessary programs that run the task bar, and I fear if I find them I will always be missing one or another.

After copying the Local folder there seem to be files missing in each start menu and cortona folder... so I assume that's why its not working.

I will try a more literal recursive copy and diff it to make sure there are no files missing. And get back here if it works. In the meantime is there something else that could be going wrong? Permissions? Is there a better way of doing this I am not aware of?

Logan
  • 31

1 Answers1

1

What was Wrong?

So, I figured out what was wrong upon doing a Copy-Item -Recurse -Force in powershell. This copy call copies junctions as empty folders (not realizing they're junctions). You could probably create a junction to wherever the original junction takes you and put it in the Local folder on the other drive, which I have no doubts would work, but that also seems like a lot of extra volatile work. You also can't create a symlink or a junction to another junction... so that fix is out of the picture. Also, copy item doesn't maintain file attributes like hidden folders, which isn't horrible because the path isn't changed, but it's just another file difference. Maybe robocopy would do what I want... but at this point.. I don't think it's worth it.

Aside: I also learned some commands for powershell that are really useful for comparing files recursively and finding these obscurities, so here they are.

$ref = Get-ChildItem -Recurse -path ref_path

$dest = Get-ChildItem -Recurse -path dest_path

Compare-Object -ReferenceObject $ref -DifferenceObject $dest

=> means its in the ref and not the dest, <= means its in the dest and the not ref

While, the issue has nothing to do with permissions, I agree with the comment by @Daniel B on my original post. I probably shouldn't be messing with these folders, and neither should you.

My Solution

I am going to propose a solution that I am vouching to use... When an installer gives you the option to not use the user's AppData folder, choose that option. For those programs that don't do that, I will keep an eye on my AppData folder's size. When I see a folder that is from a program I installed I am going to move it to that drive and creation a junction where it previously existed. This should be relatively safe (at least from destroying your PC).

As a note to developers, don't use AppData for the entirety of your app's storage. That's annoying.

Logan
  • 31