Only micro$oft makes it possible…

Cleaning up a micro$oft mess

Part of this post is splitted out from my Command line post (and maybe others), about the newly invented Bash (complete Micro$oft Ubuntu) in windows.

The parts in this post is more related to the mess windows makes on a system drive that has to be cleaned up (for getting back storage) when replaced and being reused as a data drive only.

If you did a full clone of the old drive, you can safely just wipe the old once you verified everything is available on the new drive. This is more for those who do a clean installation on a new drive and want to keep user-files on the old drive.

Only Windows makes this mess (OneDrive)

When taking a hard drive containing OneDrive folders out and mounting it as a secondary drive, some files in the OneDrive folders might be “online only” or to be “downloaded on demand”. On that disk, which is disconnected from the OneDrive account, all the files will be there (until disconnected) but not accessible.
The inaccessible files can be detected by the “dir” command, giving the file sizes in parentheses.
One option to clean out the mess made by disconnecting the OneDrive disk is to just delete the whole old OneDrive folder, if you are sure there’s nothing there you want to keep (you files should be stored online).
If you want to be safe, keeping all the files that are available offline in the folder, you need to get rid of the “placeholder” files in there.
This is how I did, it might or might not work for you (always be careful when deleting files).
First, I removed all files in my Pictures (automatic sync from camera) folder with a block size of zero:
stat -c "#rm%brm %n" * | sed 's/#rm0rm/rm/g' >rmscript

I decided it was too much work to use that method for doing all directories recursively inside the OneDrive folder, so for the rest of the online-only files I used another method.
For this, I used the “file” command which gave an error for the inaccessible files “(Invalid argument)”:
find . -type f -exec file {} >>filinfo \;
grep "(Invalid argument)" filinfo >offlinefiles
sed "s;\./;rm './;g" offlinefiles >offlinefiles2
sed "s;: ERROR: ;' #;g" offlinefiles2 >offlinefiles3

What this does is creating a list of all the files starting from the current directory. The next command filters out the lines with the error “(Invalid argument)”. As the names in the list begins with “./”, this is then replaced with “rm ./”, creating commands to remove all the files which was filtered out in the previous command.
I then replace ” ERROR” with a hashtag to tell shell to ignore the rest of the line (“#” starts a comment, if you didn’t know).
Double check the “offlinefiles3” before executing it.

Cleaning up in AppData

For the most of the times, AppData contains only crap which can be deleted without risking loosing anything important, but if you use certain applications, that folder may contain very important data.

%AppData% (your user’s AppData/Roaming) contains settings and data for some applications:
If you have been using Thunderbird as a mail client, you will have all the local databases of email and account settings in %AppData%/Thunderbird.
Firefox (Mozilla/Firefox/Profiles) might also be valuable to save for transferring to another system.
FileZilla (ftp/sftp client) has the settings stored here.
JottaCloud (or branded Jotta-clones like Elgiganten Cloud) store its databases in “Jotta” (no matter if it is Jotta or a branded clone), for more information about the content in the databases, see my post JottaCloud secrets

WSL or Micro$oft Ubuntu

If you have been using WSL (Micro$oft Ubuntu) the default user home location is nested inside AppData/Local (not %AppData%, but you could navigate there then go one step up and enter “Local” from there).
The full location is


User created files (if you have some) are usually in ‘root’ and in ‘home’,but if you think you have modified files elsewhere (/etc or if you have mysql databases), you can search for them using the oldest known non-system file as a reference timestamp file.
To find out what files you have modified since WSL (if any other than inside ‘home’), run the command ‘ls -lta’ inside your home folder, then take the last (oldest) file in there, and run a second command in the ‘rootfs’ folder:

...1fndgsc/LocalState/rootfs# find . -type f -newer home/youruser/.bash_logout

This will list all files that have been modified since the .bash_logout file (which was my oldest file in /home)

The registry, make things even more complicated

The registry has been the main location for application ans system settings since Windows 95, and will probably be so for a long time into the future.
When you have taken your old system disk offline, and on a new clean installation discover that settings have been lost in all applications there exists some ways to recover contents from your old drive.

In your user’s home directory, usually c:\users\youtoldusername, there is a file called NTUSER.DAT (probably hidden, but you should know how to google to find out how to be able to see and access hidden files). This file is the container for your old user’s settings, a ‘hive’ in HKEY_USERS. This cam be imported using regedit, and at the import time you will be asked to give it a new name (so it won’t overwrite any existing registry content).

One application I use/have used in the past, and assume at least some of you who find my posts is using is PuTTY.
Once you have imported the old registry, you will find the PuTTY sessions in whatever you named your import, followed by:


Click the “Sessions” node,then right click and export.

To import the settings to your user on any other computer, you have to search and replace content in the exported “.reg” file:




This will overwrite existing values with the content from the import, so it’s up to you to preserve the values you wish to keep (export, to import-overwrite again). If you have not yet started the application (in this case PuTTY) to import settings to, you will have to do that before, otherwise the import would fail (regedit will not create the folder “key” or the full path down to that key if it does not exist, but it will report that the import was successful even when it fails).