Hey guys, I'm in the process of setting up a new 64-bit Win 7 Pro install onto an older, newly formatted SATA HDD as a backup machine and am moving the users, program files (incl. x86) and programdata folders to the D: partition of the drive. NB. I'm not really after a lecture on why moving these is either right or wrong - the idea is that in the event of a reinstall being required, the settings etc. don't get overwritten/lost and only the C: drive gets touched. This has worked on two prior installs, so unless anyone can advise that this is definitively not workable in the event a reinstall is required, then that's a separate conversation (and actually one I've started a separate thread on) - thanks! I'm at the stage of the install where Windows is asking for country/region the second time around, after I've run a script to move the users and programdata folders in audit mode, per a post on the sevenforums site. The script has worked fine in the past for my Home Premium retail CD when installing that version but this time I've removed the ei file from the files on the CD and used wintoflash to copy across to a bootable SD card, so I can install Pro when the key gets here (in the post). Anyway, the process is going fine as before, until the point where I try to robocopy the programdata folder over to check it's moved correctly, whereupon the command prompt copies some files that evidently either didn't get moved or were just created, then gives the message "The requested operation cannot be performed on a file with a user-mapped section open". I have no idea why this is occurring, but it seems to be related to files in the Microsoft/Search/Caches folder with long alphanumeric strings for names. I have disconnected the data drive, the license key IS valid but hasn't been needed at this stage of the install yet, so that's not an issue and I've pulled out all hubs, multi-card readers etc. so only the C:, D: and F: (USB) drives are seen by the PC. Grateful if anyone can help with this.
another process has an open file handle for the file. This is frequently anti-virus, but it could also be your backup software or some kind of indexing software. Give ProcessExplorer a try: http://technet.microsoft.com/en-gb/sysinternals/bb896653.aspx. Click on the binoculars to search. Hopefully that should shed some light on what has a lock on the file.
Thanks aramil. I did come across that in my searching, but the problem I have is that I'm doing all this from a cmd prompt outside of the first install of the OS. As such, there is no AV installed and no backup running. I can get Task Manager up, but obviously that doesn't show the same sort of thing. And as far as I'm aware, I need to be in the system to download and run ProcessExplorer.
Alternate data streams allow more than one data stream to be associated with a filename. https://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_.28ADS.29 If its barfing on programdata it maybe a ADS, Hard links, Junction points, or Symbolic links Try adding "/MIR" to mirror a directory tree (equivalent to /e plus /purge). For additional information, see Remarks. http://sacookbook.blogspot.co.uk/2011/02/moving-cusers-and-cprogramdata-to.html robocopy "C:\ProgramData" "D:\ProgramData" /mir /xj EDIT: BTW i tried to do what i think your trying to do, use another drive for important user files/settings. In the end the problems trying to get it working out weighted the trouble of just using task scheduler to run a batch file to copy the important stuff to the other drive. I think windows backup will do the same thing if restoring the files needs to be made easy for non tech savy ppl.
Cheers Corky - that's some pretty in-depth shizzle. Do you reckon I then have to faff about trying to delete the original programdata folder or just leave it where it is and amend the registry default (since the existence of the original folder won't let me create a junction point)? Appreciate the assistance, bud.
If you really do want to give it a try you would need to remove the original programdata folder and then create a junction point to the new location, mklink /J C:\ProgramData D:\ProgramData A word of warning though, Microsoft say the following... http://support.microsoft.com/kb/949977
Okay, I read through the link you copied (cheers) and I took it as this: These warnings were included before the servicing stack update (update 937287) was available. This update addresses the issue that is discussed in the warning text. Windows AIK and the Windows OPK documentation reads as follows. The Important notes no longer apply. Issue with updating and SPs has since been addressed? This is probably true since the laptop I'm on has the same changes applied and the Win Updates seem to go through okay The Caution notes still apply. You will not be able to upgrade such installations to the next version of Windows.But I should be able to do a clean/reinstall over the top, as all user data will be on a separate drive Caution: Using ProfilesDirectory to redirect folders to a drive other than the system volume blocks upgrades. Using ProfilesDirectory to point to a directory that is not the system volume will block SKU upgrades and upgrades to future versions of Windows. For example if you use Windows Vista Home Premium with ProfilesDirectory set to D:\, you will not be able to upgrade to Windows Vista Ultimate or to the next version of Windows. The servicing stack does not handle cross-volume transactions, and it blocks upgrades. By including junction points, doesn't the system "see" the folders as still being stored on the system drive and therefore applies updates normally? If Windows is re-installed on the system volume, a user with administrative rights can manually recover data from this location.This is the end result I'm hoping to achieve, with the benefit of keeping the system partition small enough to go on a cheap SSD. It might also answer the questions below I thought you might be able to help with I've just checked the laptop I'm on and it actually still has a residual programdata folder on the C: drive that I didn't know was there. From the dates, it looks like it's in use, but very, very minimal use. Probably by programs that ignore default settings (even though the registry is hard-coded to D:, oddly) so maybe it's not vital that this one is moved/deleted. Not a big fan of loose ends though... The other thing I'm pondering is - if I'm moving all the relevant folders to D: and need to one day reinstall over C:, will the programs need to be reinstalled regardless, as it will be a new registry on C:? And if so, is it possible to either backup and restore the registry post-fresh reinstall over C:, or even to do the same but with individual reg keys to get the programs to work again without reloading them? The MS comment above ("If Windows is re-installed on the system volume, a user with administrative rights can manually recover data from this location") suggests to me that you can copy over the user profiles and (program?) data but that the programs would need to be reloaded. What do you reckon? If the only benefit of all this is that space is saved on the system partition, as opposed to time saved on reloading apps etc., I'm starting to think that it might be worth having a larger SSD since prices are coming down and instead just backing up the info in similar fashion to your mirror suggestion. Thanks for all your input so far, by the way...
The programdata folder on the C drive probably contains junction points to other folders, using cmd prompt do a "dir c:\programdata /a" and if contains junctions it will list where they lead, depending on the extent of what you have moved they may need to be remade. I'm a little sketchy on restoring registry setting from a previous install im afraid, as i normally do a fresh install using my own unattended image with software and setting incorporated in it. But AFAIK some parts of the registry can be imported from old to new installs but not if it includes the SID's as they should be unique to each install, but im not sure if that includes creating a new machine or user SID when doing a upgrade.
