I wanted to move from a 1.5TB hard drive to a 2TB one, so I copied all files, turned off the computer, replaced the old with the new and rebooted.
I made sure the drive letter of the old, M:, was assigned to the new, and rebooted again, just to be sure.
Everything seems to be OK – files & folders look exactly as before. Various programs can access any file or folder if I open or import them in the normal way for that program.
But programs that use scripts which store auxiliary, related files are confused and claim the files they are looking for do not exist. I can manually navigate to the desired file and the program opens it OK and proceeds normally thereafter. Note that both the old path/file name (the one it could not find) and the new one are identical.
It might not seem like a big problem, but my major focus on this drive is using Power Director 8 to edit video files. Each script file may reference from one to hundreds of other files (MPG, JPG, TIF, AVI, etc.) and it looks like I may have to find each one manually in order to edit a video.
So is there any system parameter that needs to be changed? Both Computer Management and properties functions report that drive M: is the same as it was, except larger (and a different serial number). It’s even in the same SATA slot in the drive bay.
I just thought of something that I haven’t tried…maybe the volume name of the new drive needs to match the old. I’ll report back shortly.
Nope…I made the volume name of the new drive the same as the old, even with respect to the case, rebooted, but the problem still exists. Apparently the scripts are storing something in addition to the drive letter, path and file name, but I can’t figure out what that is or how to fix it.
Did you make an exact image of the old drive’s contents in the new? ISTR that merely manually copying a drive’s contents will miss various hidden system files. But I could be wrong–it’s been a while since I transplanted a Windows system.
There are no applicable hidden files. No it’s not an image copy, but a file-by-file copy. This is not a system drive; it is used only for data.
The main program is Power Director 8. I frequently copy folders on/off a working drive for backup & archive storage with no problems. PD stores the drive letter for all associated data files, so I have a problem if I try to copy a block of data from F: to M:. In that case, I have to manually re-address each linked file. But I have been able to copy files from M: to something else, then back again to M: with no addressing problems.
Just tried another experiment…I erased a folder on the new M: and copied the same folder from the old M: (now addressed as I: thru an external USB port).
Power Director still has problems finding the files, so there must be something integral to the drive that it is looking at, not something in the files. Could that be the SID?
I don’t think the SID (System ID) is a factor here, as that should not have changed just with a drive swap.
But on a similar note, I copied the volume ID from the old (formerly M: ) to the new M: using a utility called volumeID.exe by Mark Russinovich. I think a similar program is available thru Microsoft Sysinternals. This is different from a drive label.
So now the new M: has the same Volume ID (and label) as the old. Reboot. Power Director still can’t find the files, so this must not be the problem.
As I was messing around with these tests, I noticed something… I wish I could delete this entire thread, as the problem is entirely my fault. :smack:
In the old drive, I had all files in a sub-dir under “M:video/”. In the new drive, I had mistakenly copied everything to the M:\ root instead of the \video sub-dir. This would explain everything, as any old paths would not be found in the new directory structure.
One good feature in Windows that saved me from having to copy all files from scratch is that Win is smart enough to know that a MOVE function to the same drive does not require any actual moving of the data, just an adjustment of the directory pointers. That makes “copying” of 1TB into a few second operation instead of a 12 hour procedure.
After doing that, tests show that the file addressing problem no longer exists.
What have we learned? That the drive label name and volume ID are irrelevant to file access.
Also, I should check more carefully before proceeding.
Thanks to everyone who contributed to this thread.
I’m familiar with cloning equal-sized partitions, but I wasn’t sure if it would work with a smaller-to-larger drive/partition, and I knew that a file-by-file copy would. Besides, I don’t have any cloning software handy that works with XP.
Also, while cloning is often a great idea, file copying also defrags at the same time while cloning doesn’t, and that can be an advantage sometimes.
Well, if your software can’t clone to a larger partition, it’s no big deal: just make the partition the same size as the original, and then enlarge it after the fact. You’ve already got a backup on the old hard drive (and, honestly, I’ve never actually had to use my backup when I non-destructively resized a partition.)