Create Junction point for Program Files (x86) on functioning system

Question

Recently I found that my lowly 128GB SSD was filling up to the point where I had to uninstall old games to install new games. That wasn't bad until I had to install some other applications for actual doing work and now I just don't have enough space to even do that anymore

So I know the solution to what I want to do. It's the same thing I did when I was building disaster recovery into my system, just create a junction point and point it to a 1TB HDD in the computer. So just like creating a junction for c:\users and pointing it to the internal HDD I would just copy the Program Files (x86) folder over to the HDD, reboot into safe mode w/ command prompt, rename Program Files (x86), then create a junction with that folder name. I found something that I'm sure is a windows issue, and since i'm a Linux admin I figured I would take to the boards since I couldn't find a problem similar on google.

TLDR; I can't rename Program Files (x86) from within windows so I restarted into safe mode w/ command and was able to rename it, and I was able to create a junction point with the same name...

rename "Program Files (x86)" "Not_Program Files (x86)"
mklink /J "Program Files (x86)"  "D:\Program Files (x86)"

Now it gets weird. I boot back into windows and see Program Files (x86) directory is still there, and any directory with what it SHOULD be named now doesn't exist. But wait.... there's more! When I look at the file properties of Program Files (x86) the object is being referred to as what I renamed it to.

My question REALLY is why won't windows rename this directory and how can I accomplish what I'm expecting?

here is a link to the properties of the folder which shows that the "object name" is an expletive that I made kid friendly. ( no rep to include in post )

https://i.sstatic.net/4stDi.jpg

Answer 1

I don't think you should be messing with the Program Files directories. Windows has special restrictions on them for a reason, and tampering with it can produce unwanted results.

I would instead suggest that you create directory junctions on a program-by-program basis. Start with the programs you don't use often, followed by the ones which take up a lot of space (Games are pretty notorious for this, with all the texture files, video and sound clips etc).

Of course, it may be easier to directly uninstall each program and reinstall them, changing the install path to point to your second HDD in the process.

Answer 2

To keep it short I had to remove the -S attribute from the folder which indicates system ownership (probably) from the command console i was able to run

attrib -S "Program Files(x86)"

then rename the folder and create the junction point. The only real side effect I have notices is that several existing shortcuts, mainly ones that were pinned to the start menu or taskbar, stopped working. That is easily corrected by simply recreating them, I had less luck just changing the shortcut properties since the path was the same verbatim.

Regarding the potential risks involved in doing something like this, I'm fully aware I could be looking at a full reinstall, but I'm cool with that. Rules are made to be broken otherwise what is the point int being superuser? I will say thank you though, for noting that this is not something people with limited sysadmin experience should attempt. This project still may have unintended consequences, but for now I'm happy with the statof my box.

Answer 3

Some time ago, I was doing something really similar, but with two SSD 120GiB.

System partition was getting too big, they start to need a total size of 64GiB for each Windows (to ensure 60% is free for upgrades), and I have three.

I am not going to enter on low level details, just point this:

• Second SSD (where Slim DVD was) is not powered until OS is loaded, so I can not use it in Grub2 bootloader, I can not boot from it and I can not do anything on it till any OS is loaded; same for SD slot and for ExpressCard54 slot; all of them are not powered while BIOS runs at boot.

Since Program Files and Program Files (x86) have near 1/3 of the total in use size, I was thinking to move that GiB's to the second SSD, with MKLINK /J ... tricks.

So, I ensure that the SSD is powered as soon as Windows Loader is running, much prior to when such folder is needed, it is powered just a little prior to windows logo bring on screen, so must not be any problem for junction be there; so I give a general warning here: use junction (/J), not a symlink (/D), weird things too long to explain happens when it is a symlink (most when you do an upgrade on Windows 10, from 1709 to 1803, etc).

Always, I repeat, always try these as proof of concept on virtual machines prior to you main machine.

Not the ADD to you:

• You can do the same trick for pagefile.sys and swapfile.sys to put them away, where ever folder/subfolder you want, use commands like MKLINK C:\pagefile.sys M:\MySubFolder\MyNameForPageFile.DAT and MKLINK C:\swapfile.sys M:\MySubFolder\MyNameForSwapFile.DAT

Two points on that:

1. To be able to create the hard link (not junction, not symlink) you must boot with virtual ram deactivated (if it was active you must reboot after deactivate it), so there is no pagefile.sys nor swapfile.sys on root of system partition, then create the hard links, then activate the virtual ram
2. If you have multiple windows (multi-boot) you can re-use the same hard link target for all of them, so you only take off such space of your SSD only once, not once per windows

If you go ahead with pagefile.sys and swapfile.sys, there is a warning: Any Windows 10 upgrade will delete the hard link and re-create normal files in-place, so after upgrade you need to re-do the hard-links, deactivating virtual ram, rebooting, creating them, reactivating virtual ram.