OTish: Temporarily moving a HDD to another PC

I have a Windows 7 PC for use by the family. It has a single HDD
only. This PC needs to go back for repair (noisy PSU). How easy
would it be to temporarily move the HDD, to use just as a data disk,
to another PC? I don't want to spend ages reconfiguring things when
the PC would only be gone for a short time.

On 03/09/2014 05:47 AM, Mark wrote:
I have a Windows 7 PC for use by the family. It has a single HDD
only. This PC needs to go back for repair (noisy PSU). How easy
would it be to temporarily move the HDD, to use just as a data disk,
to another PC? I don't want to spend ages reconfiguring things when
the PC would only be gone for a short time.


For temporary use, you might want to use a USB adapter like this:

http://www.amazon.com/Drive-Adapter-...b+sata+adapter

I use one frequently, and it saves a lot of work. You don't have to
reboot to use it.

--
Mark Lloyd
http://notstupid.us

"Might there have been fewer crimes in the name of Jesus, and more mercy
in the name of Judas Iscariot?" [Thomas Pynchon]

On Sun, 09 Mar 2014 10:23:02 -0500, Mark Lloyd
wrote:

On 03/09/2014 05:47 AM, Mark wrote:
I have a Windows 7 PC for use by the family. It has a single HDD
only. This PC needs to go back for repair (noisy PSU). How easy
would it be to temporarily move the HDD, to use just as a data disk,
to another PC? I don't want to spend ages reconfiguring things when
the PC would only be gone for a short time.


For temporary use, you might want to use a USB adapter like this:

http://www.amazon.com/Drive-Adapter-...b+sata+adapter

I use one frequently, and it saves a lot of work. You don't have to
reboot to use it.

I probably posted to the wrong newsgroup. It's more of a software
issue of how to access the data from the disk on another PC so the
family can still see their documents, emails etc without too much
effort.

On 09 Mar 2014, Mark wrote in
alt.comp.hardware.pc-homebuilt:

I probably posted to the wrong newsgroup. It's more of a software
issue of how to access the data from the disk on another PC so the
family can still see their documents, emails etc without too much
effort.

You don't say it, but I'm assuming you plan to put the disk back in the
original PC when it's returned.

I would hook the disk up to the temporary PC and then copy their data
off of it onto the temp PC. Then I'd disconnect the disk and put it
away in a safe place. Then, when you get get the original PC back and
you put the disk back into it, I'd copy any changed or new data files
off the temp PC back to their permanent home.

I'd rather keep the original disk offline for safety's sake.

Mark wrote:
I have a Windows 7 PC for use by the family. It has a single HDD
only. This PC needs to go back for repair (noisy PSU). How easy
would it be to temporarily move the HDD, to use just as a data disk,
to another PC? I don't want to spend ages reconfiguring things when
the PC would only be gone for a short time.

Without understanding the details of "why", I'd be a little
careful about moving those files. See how many happy users
are in these threads.

http://answers.microsoft.com/en-us/w...3-52d7b1a0e922

http://serverfault.com/questions/154...to-new-machine

If you make a "clone" of the Windows 7 drive, then connect that to the
foreign PC, you can use takeown and friends to your heart's content.
To allow reading the drive on the other PC.

I vaguely remember somewhere, you'd not supposed to "takeown" a
system partition, from the root level. So there appear to be
some places, where modifying the permissions can have consequences,
like trying to boot later.

If it was a "data-only" drive you were doing this to, I'd have
no concerns with moving it back and forth. You could takeown on
either end, and slosh files back and forth. But, as this drive
has a C: operating system on it, you could mess it up. And
some of the users in the above thread, appear to have done just
that.

If you worked in data-only subfolders of the C: drive, you would
probably "live to fight another day". Just be careful not to be
too efficient, and do " takeown /f C: " or the like. Without
doing more research to figure out what that breaks in the long
term.

It really shouldn't break anything, which is why I don't
understand the issue. Adding a user to have permissions
to a file, I don't see how that breaks it.

So for safety, it's just easier to clone the drive, before
it leaves the house. The family can treat the drive read-only,
with the promise that when the original PC is put back together,
the clone drive will be erased. If you point that out, they're less
likely to fill it with modified files. And store their modifications
some place safe for later.

*******

You can see in this thread, the guy uses two commands. The first
command, gives him access to the files, to make further changes.
The second command, appears to add permissions, like giving
"full control" where full control may not have been set previously.
You can probably see from this, things are being permanently changed
from a permissions point of view.

http://blogs.msdn.com/b/tims/archive...deletable.aspx

I wish there was a way to back up just the permissions bits, and
restore them later, but that's just too easy as a concept. So
instead, cloning the disk, is the next best thing, in terms
of safety. Give the family a "copy" of the disk to mess up
(prepared on the original machine), and "no one gets hurt"
when the clone is used on the foreign machine. Because you just
know Windows is going to whine when they attempt to open files
over there.

Paul

On Sun, 09 Mar 2014 15:13:01 -0400, Paul wrote:

Mark wrote:
I have a Windows 7 PC for use by the family. It has a single HDD
only. This PC needs to go back for repair (noisy PSU). How easy
would it be to temporarily move the HDD, to use just as a data disk,
to another PC? I don't want to spend ages reconfiguring things when
the PC would only be gone for a short time.

Without understanding the details of "why", I'd be a little
careful about moving those files. See how many happy users
are in these threads.

One of my intentions is to try to avoid moving any files, if possible.
I wish to minimize the time I need to spend on this.

http://answers.microsoft.com/en-us/w...3-52d7b1a0e922

http://serverfault.com/questions/154...to-new-machine

Permission problems is the least of my concerns. I don't believe I
have explained the issues very well!

If you make a "clone" of the Windows 7 drive, then connect that to the
foreign PC, you can use takeown and friends to your heart's content.
To allow reading the drive on the other PC.

I wasn't planning to attempt to clone any drives. I don't have a
spare HDD big enough to do this. If I did I'd still have to copy
files back to the original disk when the PC is returned.

I want to install a minimal OS on a new (smaller) disk (an SSD) and
attach the "old" HDD to the same PC. I want the family to be able to
access their emails/documents etc without me having to spend a week
setting everything up. Maybe what I want is impossible. When the old
PC is returned I want to refit the disk and it still work there.

I vaguely remember somewhere, you'd not supposed to "takeown" a
system partition, from the root level. So there appear to be
some places, where modifying the permissions can have consequences,
like trying to boot later.

If it was a "data-only" drive you were doing this to, I'd have
no concerns with moving it back and forth.

Me neither. But then I wouldn't have ever started this thread if this
had been the case ;-)

So for safety, it's just easier to clone the drive, before
it leaves the house.

The drive isn't going to leave the house. I intend to return the PC
with no HDD fitted.

The family can treat the drive read-only,
with the promise that when the original PC is put back together,
the clone drive will be erased. If you point that out, they're less
likely to fill it with modified files. And store their modifications
some place safe for later.

This isn't the issue. Most of the family are not technical and expect
things to just "work". And right now I don't have the time to do a
lot of work on this.

Mark wrote:


This isn't the issue. Most of the family are not technical and expect
things to just "work". And right now I don't have the time to do a
lot of work on this.



OK, I have an idea.

What about installing an OS on the SSD. Then, use Windows Easy Transfer,
to transfer the user accounts from the old hard drive, to the SSD.

Steps:

1) Plug SSD into source machine.
2) Create two partitions on the SSD. Estimate the size of the family
files, to work out a reasonable size for the temporary partition.
One partition will become C: (and is empty at this time), while
the other partition is D: temporary data.
3) Run WET and transfer the accounts to D:
4) Move the SSD to the destination machine.
5) Install an OS. The OS installer should have an option,
to allow you to "select" a partition. You can select the
first partition on the SSD for that task, the empty one.
My Windows 7 laptop uses 40GB, and that would be sufficient
for the moment.
6) Once the installation is complete, now you're booted off the
SSD. Run WET again, pulling in the accounts off the D: partition.

It's also possible to stage the WET files on the originating
machine, and transfer them over the network to the SSD machine.
That's if you don't have sufficient space to do it on the SSD.

Windows Easy Transfer should take care of any permission
issues, when it moves the files to the destination.

http://en.wikipedia.org/wiki/Windows_Easy_Transfer

HTH,
Paul

On Sun, 09 Mar 2014 17:25:23 -0400, Paul wrote:

Mark wrote:


This isn't the issue. Most of the family are not technical and expect
things to just "work". And right now I don't have the time to do a
lot of work on this.



OK, I have an idea.

What about installing an OS on the SSD. Then, use Windows Easy Transfer,
to transfer the user accounts from the old hard drive, to the SSD.

Steps:

1) Plug SSD into source machine.
2) Create two partitions on the SSD. Estimate the size of the family
files, to work out a reasonable size for the temporary partition.
One partition will become C: (and is empty at this time), while
the other partition is D: temporary data.
3) Run WET and transfer the accounts to D:
4) Move the SSD to the destination machine.
5) Install an OS. The OS installer should have an option,
to allow you to "select" a partition. You can select the
first partition on the SSD for that task, the empty one.
My Windows 7 laptop uses 40GB, and that would be sufficient
for the moment.
6) Once the installation is complete, now you're booted off the
SSD. Run WET again, pulling in the accounts off the D: partition.

It's also possible to stage the WET files on the originating
machine, and transfer them over the network to the SSD machine.
That's if you don't have sufficient space to do it on the SSD.

Windows Easy Transfer should take care of any permission
issues, when it moves the files to the destination.

http://en.wikipedia.org/wiki/Windows_Easy_Transfer

Thanks. That looks good. I guess I can use the same method to
transfer the updated files back onto the original drive?

Mark wrote:
On Sun, 09 Mar 2014 17:25:23 -0400, Paul wrote:

Mark wrote:

This isn't the issue. Most of the family are not technical and expect
things to just "work". And right now I don't have the time to do a
lot of work on this.


OK, I have an idea.

What about installing an OS on the SSD. Then, use Windows Easy Transfer,
to transfer the user accounts from the old hard drive, to the SSD.

Steps:

1) Plug SSD into source machine.
2) Create two partitions on the SSD. Estimate the size of the family
files, to work out a reasonable size for the temporary partition.
One partition will become C: (and is empty at this time), while
the other partition is D: temporary data.
3) Run WET and transfer the accounts to D:
4) Move the SSD to the destination machine.
5) Install an OS. The OS installer should have an option,
to allow you to "select" a partition. You can select the
first partition on the SSD for that task, the empty one.
My Windows 7 laptop uses 40GB, and that would be sufficient
for the moment.
6) Once the installation is complete, now you're booted off the
SSD. Run WET again, pulling in the accounts off the D: partition.

It's also possible to stage the WET files on the originating
machine, and transfer them over the network to the SSD machine.
That's if you don't have sufficient space to do it on the SSD.

Windows Easy Transfer should take care of any permission
issues, when it moves the files to the destination.

http://en.wikipedia.org/wiki/Windows_Easy_Transfer

Thanks. That looks good. I guess I can use the same method to
transfer the updated files back onto the original drive?


It's going to be more complicated on the way back.

To do a thorough job, you'd need a manifest of what was copied over.

On the SSD, the file date stamps are a good source of evidence.
The directory date stamps aren't of much use. You can't trust them.

Windows is also real sneaky about this stuff. It considers a file
"copied" to another disk, to be "created" on it. Only certain utilities
can be trusted to preserve dates. I'm hoping WET is one of those. You'd
get different results with WET than you'd get with DOS "copy" command.

You can list the files by date. The /S here is recursive (list the
whole tree).

dir /S C:\ output.txt

Do a run before WET on the SSD. Do a second run with a different output
file name, after WET brings the files over.

Then, use "diff" to compute the manifest of files brought over. At
least this may hint at what directories are getting changed. Diff is a
utility that compares lines of text in two text files, highlighting
the changes and the parts that remain the same. A port of "diff.exe"
is available in diffutils, but you need the .dll files in the dependencies
download, to be in the same directory as the binary executable.

http://gnuwin32.sourceforge.net/packages/diffutils.htm

diff output1.txt output2.txt my_copied_files_to_SSD.txt

The reason I'm going to all this trouble, is I can't be sure I know
where all the changed files will be. While I suspect they're in
C:\users\Mark , there may be other places that changes have occurred.
Where are email databases stored ? Do you expect the browser bookmarks
to come back ? Firefox profile folder ? And so on.

*******

Generally speaking, for the return trip, you want "file syncing" software.
But to use "file syncing" in a safe way, you need a list of directories
to make it possible. The OS folder on the SSD C: drive, is going to be
quite different than the source drive, and syncing it over would cause
havoc.

For example, if I thought all the files were in C:\users\Mark on the SSD,
I could use file syncing between D:\users\Mark (when the SSD is plugged
into the original desktop, and shows up as a data disk), and C:\users\Mark
on the original machine. The sync software then sees to it, that the
original directory is only overwritten, by files with later date stamps.
You have to be careful about the difference between syncing and mirroring,
as mirroring can cause files to be deleted at the destination. Whereas
syncing just copied files with a later date, or files that do not
exist at the destination. Syncing is "additive", so no files should
get deleted.

http://en.wikipedia.org/wiki/Compari...ation_software

There might be file changes in appdata, or in other places.
Using "file manifest" methods, is intended to locate where
all the changes will be coming from.

I have other techniques for generating manifests. Using a
Linux LiveCD, these two commands make separate lists of files
and directories. In this case, the date change on the files will
be of interest. This syntax makes nice file names followed by dates,
which can be post-processed easily. The "dir" example, needs to be
converted from hierarchical format to flat format, which takes a
script.

find /media/WINXP -type d -exec ls -al -1 -d {} + /tmp/directories.txt
find /media/WINXP -type f -exec ls -al -1 {} + /tmp/filelist.txt

There might be some utility that can output in that format
on Windows (Treeview?), but I don't have an extensive set
of such utilities here.

*******

Maybe I'm making this harder than it has to be, but I'm trying
to be thorough. If you were to use WET, it's going to whine about
attempting to make new user accounts (duplicates) with the same
SID information as accounts that are already there. I don't see
a big win by doing this. I can only see trouble, by using WET
for the return trip. Even a search, listing files by date,
would be a start at identifying changes.

In Windows7, File Explorer search window, you can use
advanced search syntax. Complete with tiny calendar box :-)
You can do this on the SSD end, to estimate the extent of the
job after the SSD machine is no longer being used.

http://www.addictivetips.com/windows...date-and-size/

Paul