Clean Up Appdata Windows 10l
Stephanie Dejoode
AppData folders store per-user information for applications, so if you delete files from an application's applications data directory, it will likely have to recreate that data from default values. In effect the program will forget that you have used it before, configuration choices you may have made, saved files (like game savefiles), etc.
I would recommend you use a tool like windirstat to determine where the space is being used, and what application(s) rely on it. From there you can then begin to determine the impact of your proposed deletion.
As commented, some applications like WSL and apps from the windows store will rely heavily on Application Data storage, to the extent that deleting the files from App Data is akin to uninstalling the application (in a clumbsy, unclean way), so understanding the way a particular app uses Application Data is quite important when determining what you can remove.
I'm using docker for Windows to launch a MSSQL server. Everything is working fine except for the fact that my harddrive is now full. I've used all the cleanup commands that docker has, removing all images and containers:
This will not remove any contents in the c:\ProgramData\Docker\windowsfilter folder, where there are still a lot of file. Roughly 130gb worth's of storage, without any running containers or stored images.
The workaround is adding -removing suffix to the folders you wish to delete within windowsfilter directory and restart the docker. This will trigger docker to cleanup the folders properly at startup. I have experienced docker will clean at most 10 folder in every startup. If you have more then 10 folders, then you might restart several time to remove all of them.
I would be extremely cautious here. There is a reason this folder is kept hidden. Microsoft does not want you to mess with it. If you delete anything in AppData, you might find that Internet Explorer no longer works. Or Firefox. Or any of the other applications you have installed. If you have a large number of applications installed, then it stands to reason that the size of the AppData folder will also be large. It's size will change as you install or uninstall any applications/programs.
That being said, there is one very specific folder in AppData whose contents are safe to delete. It lies in the path C:\Users\\AppData\Local\Temp. Just be sure to delete only the contents of this folder and not the folder itself.
I was thinking along the same lines. 150gb is big as mine is only 350mb. I'm wondering if there may be some program which isn't cleaning up after itself, such as video/audio converting software using that location for it's temporary converting process and associated data, and then leaving it behind.
Another thing worth mentioning is that not all software cleans up properly after itself when uninstalled. Usually appdata and local appdata folders are left behind but sometimes even Program Files (XP name) stuff is left behind, which is why dedicated "Install Tracker" and "Uninstaller" programs exist.
The AppData system folder in Windows is the default location for application data, settings, and caches. Over time, it can become bloated with unnecessary files, which can lead to slower performance and take up free space on your hard drive.
In this example, you can see that the size of the AppData folder is about 21 GB. The graphical folder map in WinDirStat allows you to quickly find files and folders that are taking up a lot of free space. In our case, we quickly found a large vhdx image in the \AppData\Local\Packages folder left over from experimenting with WSL.
However, in most cases, you should never manually delete any folders or files from the AppData folder. Such a brutal method can harm other apps on your computer. First, use the built-in Windows tools to clean up the AppData folder.
Thanks for this article which gives a decent insight in to the workings of the appdata folder. Most of the bloat in appdata comes from the browsing folders and application folders within the roaming area of Appdata and there is no way to clean it. I hope MS will one in the distant future provide that. We may not be living by then and windows OS may not be in operation even.
I moved my Roaming folder to another drive, waited a few days then checked. The original Roaming had not changed, while the one on the new drive had expanded. As a precaution i copied the original Roaming folder to a separate location, then deleted the original Roaming folder . I then emptied the C drive Recycle bin and rebooted. All went well and my C drive is now dseveral Gigabytes lighter
I have been going through and updating my raid array and I noticed that my appdata is spread all over my array, assuredly from misconfiguring it originally years ago. I have some on the cache, and then some spread across all 6 disks in the array.
Currently I don't use the mover at all because my cache ssd is only 256GB and I drop my new movies onto the array a lot so would blow right past the max size. I want to upgrade the cache to a new ssd over black Friday.
But wont I need to move the files from the various disks they are on to the cache drive after I disable the docker, then set appdata to cache prefer? Stopping the docker then switching appdata to cache prefer wont automatically copy the current files scattered around the array to the cache drive will it?
Does switching appdata to cache:prefer also move data from /mnt/user/appdata to /mnt/cache/apppdata automatically, thus all appdata should be on my new cache drive and all my dockers should be using the cache drive?
Should I go and change the paths the dockers are using afterwards? For example, netdata has /etc/netdata/override /mnt/user/appdata/netdata. Should I change /mnt/user/appdata/netdata to /mnt/cache/appdata/netdata? Mainly because I have a mish mash of both methods across my dockers and want to normalize them to one way.
Regarding "Do something here to get appdata using the cache currently to now use the array. " you replied "The same as any other user share gets moved from cache to array, by setting it to cache-yes."
Yes indicates that all new files and subdirectories should be written to the Cache disk/pool, provided enough free space exists on the Cache disk/pool. If there is insufficient space on the Cache disk/pool, then new files and directories are created on the array.
cache is part of user shares. It is where cache-prefer and cache-yes user share data is written. Normally you want appdata to be on cache so your dockers will not have performance impacted by slower parity, and so your dockers won't keep array disks spunup.
Mover also won't move duplicates. You might be able to look at dates to decide which is the current files, but typically, the files already on cache would have priority when referencing user shares so those should be the correct ones and the others could be deleted (might back them up first just in case).
I'd like to use beyond compare to compare the files on the cache drive vs the files in the array. If the cache drive is all newer or the same I can pretty safely just delete all the files in the array that are duplicates.
I always use the built-in Midnight Commander (mc at the command line) to manage files directly on the server. But if you want to work with them over the network you will have to share the disks in Global Share Settings.
Note that you must never mix user shares and disks when moving or copying. Linux (and Windows for that matter) doesn't realize the user shares and the disks may reference the same files, so it is possible to lose data when you it tries to overwrite what it is trying to read.
Looking at the user share (/mnt/user/appdata), it says the files are spread across "Cache, Disk 1, 2, 6". So do I need to make a disk share for disk 1, disk 2, and disk 6? Once I have those three shares (disk 1, 2, and 3) created how do I compare it the files on the disk, via the disk share, with the files in /mnt/cache/appdata/linuxserverplex? Am I allowed to make a disk share for the cache as well? If so then can I compare the share for the cache disk with the shares for disk 1, 2, and 6?
It sounds like I am then free to delete files out of the disk shares. I just have to make sure I never use the share associated with /mnt/user/appdata/linuxserverplex for any of the operations correct?
Also, make sure you don't already have a user share named for a disk. It is possible to make a user share with the same name as a disk by accidentally specifying a path like that somewhere such as a docker mapping. If you have a user share named the same as a disk then you won't know what you are working with on the network. Just another reason to not share disks on the network.
Thanks, I double checked and have no user shares named the same as a disk. I looked at the main shares tab to compare user share and disk share names. If a user share was created via "accidentally specifying a path like that somewhere such as a docker mapping" it would still show up on this screen in the webgui correct?
I think I might make backups of everything and just delete any duplicate files on the disk and hope for the best, unless you happen to have any good suggestions besides file date. It is kind of hard to tell what is what inside the Plex cache folders and if I have to blow it all up then so be it.
7025e2c3df