Reseting NTFS ownership and attributes after a Windows reinstallation

Let's say you had to reinstal Windows 7, due to Microsoft having screwed so bad with its automatic update installer that it was the only option left. Now, you performed a semi-clean install, in that Windows installed a brand new copy, but moved the previous installation system directory into C:\Windows.old.

The usual problem, if you're using mutliple NTFS drives or partitions is that you may have files on these additional partitions that are owned by your previous account, which now has a completely different GUID than your new account. This means that you find that you have all the trouble in the world getting full access to files you rignfully own.

The solution?

In an elevated prompt, go to the additional drive and issue:
takeown /F * /R
icacls * /grant <your_user_name>:F /T
This will take a while, but it should reset ownerships and all these other pesky attributes that are a major annoyance to GETTING ANY WORK DONE!

Note that you can also try the following beforehand, if you want to reset all the access rights:
icacls * /T /Q /C /RESET

Changing the NTP update interval in Windows

Default is 604800 seconds (7 days), which is way way too long. On my machine, I'm getting clock skews of close to a minute as a result, and that's not acceptable when you're swapping files around for compilation for instance.

To set this value to a more reasonable interval, you need to update the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpClient\SpecialPollInterval

Windows 7, I hardly knew ye...

Blah, blah, blah, Windows 7 is great, blah, blah...

Oh, you were actually expecting something in that range? Not on this blog I'm afraid.
When Windows 7 consistently freezes within 4 hours of a fresh install (happened on Vista too, so I don't think it's a Win 7 issue only. Past that initial freeze the system is stable enough though), needs a full reinstall less than one month after it, and putting the computer to sleep or rebooting is akin to Russian roulette (will it boot again, or will just remain frozen forever and require, not only a hard reset, but a complete PSU unplug? - heck, I have a hackintosh OS-X working better than that on hardware that was never meant to be supported by Apple - go figure!)

And now, once again, it's time for a clean Windows 7 reinstall, which means reinstalling all the apps, and having to do that every few months to keep the hardware in running order (because I actually DO something with my machine you know, like installing drivers by the truckload for development purposes - it's not just for internet and multimedia) is getting a bit old.

Today's tip then is then is how to avoid reinstalling the WinDDK, when you still have the files (in E:\WinDDK\7600.16385.0\ for instance) and all you are interested are the build environment shortcuts.
Windows 7 x64 free build environment shortcut:

C:\Windows\System32\cmd.exe /k E:\WinDDK\7600.16385.0\bin\setenv.bat E:\WinDDK\7600.16385.0\ fre x64 WIN7 no_oacr

Same thing for x86:

C:\Windows\System32\cmd.exe /k E:\WinDDK\7600.16385.0\bin\setenv.bat E:\WinDDK\7600.16385.0\ fre x86 WIN7 no_oacr

And for reference, setenv usage:

Usage: "setenv  [fre|chk] [64|x64] [WIN7|WLH|WXP|WNET] [bscmake] [no_oacr] [separate_object_root]"

Task Manager Windows Shortcut

Found that one totally by accident (and yes, sometimes it doesn't hurt checking the official Microsoft documentation): <Ctrl> <Shift> <Esc> = bring up the Task Manager

Now, give me a shortcut to bring up the Device Manager (well, you can go there in 2 steps, through <Windows <Pause/Break> (= System Information) -> Device Manager, but still...

Oh, and of course, you want to replace the default Task Manager with Process Explorer, as the shortcut works for it too.

Why does windows find the need to modify the partition table at boot...

...or how I almost lost 1.5 TB of data today.

If you use software/fake RAID, this might happen to you too.

See, this morning I thought I would upgrade my HTPC's BIOS just for the heck of it. This is the PC that has a 2TB RAID5 array based on nVIDIA's MediaShield.
Now, despite what I had selected during the BIOS update, the BIOS settings and DMI data were reset after reboot, which means that the HDDs were back to individual IDE emulated drives, rather than members of the RAID array.

Normally, this wouldn't be a big deal, except that, before I cancelled the Windows boot, it was apparently able to look at the disks (using the MediaShield driver), find out that the capacity of the disk it was booting from (now a single 1TB IDE/AHCI HDD) was less than the capacity reported in the partition table, and re-write the partition table of HDD1 to reduce the dimensions of the last partition.

Of course, re-writting a partition table without anybody asking you to is the shortest way to screw up a disk or RAID array, and screw up it did: As soon as I restored the RAID settings in the BIOS and booted Windows, my 1.5 TB data partition was now identified as unformatted and gone! Talk about massive data loss...

No respectable O/S should ever modify a partition table without asking the user first. It's just common sense: The O/S is never, and I have to stress out that part, NOT EVER, smarter than its user (no matter what the O/S developers might think, or how smart they think they are themselves). You do not modify a partition table without asking, EVER, it's really simple as that!

Now, after much cursing, and some accidental good luck, I found that if the first drive was disconnected from the RAID5 array (which happened accidentally as I was trying to invert HDD#2 and HDD#3, since it originally looked like the BIOS upgrade has modified the SATA IDs), the rest of the array booted fine, albeit in degraded mode, and saw the old 1.5 TB data partition alright. Definitely makes sense with the fact that Windows would of course only have modified the partition table of the boot drive while the HDDs were in IDE mode.
But of course, as soon as you remove one drive from your RAID5 array, and boot in degraded mode, the array will flag that drive as failed on next reboot

From there on, the solution is to re-add the drive to the array to resync. Takes a while, but if you trust your other disks not to fail duing the super-lengthy re-sync, probably the safest solution.
Otherwise, it's probably a good idea to have a copy of the Master Boot Record (i.e. the first 512 bytes) of every single drive from your array, and restore it using a decent O/S like Linux. Plus, as experience will show you time and again, it's also always good practice to keep a copy of the MBRs of all your disks that contain important data, so that you can try to address any kind of partition formatting catastrophe.

Windows Command Prompt in UTF-8

1. Change the default font to Lucida
   
2. issue the command chcp 65001