Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.ibm.pc.hardware.storage > #2311 > unrolled thread
| Started by | AndyHancock <andymhancock@gmail.com> |
|---|---|
| First post | 2012-01-06 22:57 -0800 |
| Last post | 2012-01-14 21:42 -0800 |
| Articles | 20 on this page of 43 — 5 participants |
Back to article view | Back to comp.sys.ibm.pc.hardware.storage
Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-01-06 22:57 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-08 07:18 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-01-08 16:17 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-09 13:53 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-01-11 22:22 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-12 19:34 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-01-13 21:08 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-14 16:32 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone Mike Tomlinson <mike@jasper.org.uk> - 2012-01-13 11:46 +0000
Re: Initialize / format 500 GB Momentus XT to make bootable clone Arno <me@privacy.net> - 2012-01-13 17:08 +0000
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-01-13 21:14 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-14 16:41 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-01-14 21:38 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-15 20:37 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-01-15 21:23 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-16 20:14 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-01-16 20:57 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-17 19:44 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-02-15 20:48 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-02-16 16:10 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-02-16 20:50 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-02-17 04:26 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-02-18 00:58 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-02-19 15:04 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-02-20 10:55 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-02-19 21:27 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-02-20 20:12 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-02-20 22:50 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-02-21 20:20 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-02-21 22:08 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-02-22 19:34 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-02-23 05:09 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-02-22 20:26 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-02-22 20:46 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-02-23 20:04 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-02-23 18:49 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-02-24 15:58 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-02-23 21:09 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-02-24 17:30 +1100
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-02-24 20:39 -0800
Re: Initialize / format 500 GB Momentus XT to make bootable clone Winniethepooh@100acrewoods.net (GMAN) - 2012-02-22 15:48 +0000
Re: Initialize / format 500 GB Momentus XT to make bootable clone Arno <me@privacy.net> - 2012-01-14 18:37 +0000
Re: Initialize / format 500 GB Momentus XT to make bootable clone AndyHancock <andymhancock@gmail.com> - 2012-01-14 21:42 -0800
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | AndyHancock <andymhancock@gmail.com> |
|---|---|
| Date | 2012-02-16 20:50 -0800 |
| Message-ID | <cad91427-efdb-4028-8e8f-cf5b064ef4c5@w4g2000vbc.googlegroups.com> |
| In reply to | #2642 |
On Feb 16, 12:10 am, "Rod Speed" <rod.speed....@gmail.com> wrote: > AndyHancock wrote > > > Rod Speed <rod.speed....@gmail.com> wrote > >> AndyHancock wrote > >>> I can change the boot sequence so that it boots off of > >>> eSATA-connected auxiliary drive (residing in an enclosure), > >>> but I'm told that unless I actually remove the native drive, there > >>> is a risk that the laptop will see both boot partitions and modify > >>> the registry so that one or both HDDs can't be booted from. > >> And that is correct. In fact its not only a risk its a certainty. > >>> I need to dig deeper so that I'm not gambling with my HDDs. > >> You arent gambling if you are careful about removing the original drive. > > Hi, Rod, > > Apparently, if you've booted off of the clone drive once, > > you no longer run the risk of making both drives unbootable > > if you happen to have both drives connected during boot time. > > Yes, that is correct. > > > Is this something you're familiar with? > > Yes, I have said that in here myself in the past. > > > If so, would you know if booting off the clone when it is > > in the eSATA enclosure qualifies as having booted once? > > Yes it does. > > > What about if you boot once when the clone is in the eSATA > > enclosure, then boot a 2nd time when it is in the laptop...during > > that 2nd time, would the clone be already out of the danger zone? > > Yes it is. > > > If so, it means that I can have another bootable HDD in the > > eSATA enclosure (for example, the source HDD) during bootup. > > Not during the first boot of the clone after the clone has been created. Thanks for clarifying the danger, Rod.
[toc] | [prev] | [next] | [standalone]
| From | AndyHancock <andymhancock@gmail.com> |
|---|---|
| Date | 2012-02-17 04:26 -0800 |
| Message-ID | <2488c10c-b237-4932-91cf-48dbb06f8ee9@m2g2000vbc.googlegroups.com> |
| In reply to | #2649 |
On Feb 16, 11:50 pm, AndyHancock <andymhanc...@gmail.com> wrote: > On Feb 16, 12:10 am, "Rod Speed" <rod.speed....@gmail.com> wrote: >> AndyHancock wrote >>> Apparently, if you've booted off of the clone drive once, you no >>> longer run the risk of making both drives unbootable if you happen >>> to have both drives connected during boot time. >> >> Yes, that is correct. >> >>> ...would...booting off the clone when it is in the eSATA enclosure >>> qualifies as having booted once? >> >> Yes it does. >> >>> What about if you boot once when the clone is in the eSATA >>> enclosure, then boot a 2nd time when it is in the laptop...during >>> that 2nd time, would the clone be already out of the danger zone? >> >> Yes it is. >> >>> If so, it means that I can have another bootable HDD in the eSATA >>> enclosure (for example, the source HDD) during bootup. >> >> Not during the first boot of the clone after the clone has been >> created. > > Thanks for clarifying the danger, Rod. Actually, I have one more variation on the above scenarios that I'd appreciate your expertise on. Say one of the two HDDs acts as a target for weekly cloning of the other HDD, and that both HDDs undergone their virgin booting. Say the weekly cloning consists only of cloning the C-drive (partition 2 of Toshiba's 4-partition setup). Does cloning only partition 2 put the target HDD back into its virgin state of never having been booted from before, thus re-introducing the problem of making both HDDs unbootable if both are connected during a bootup? As well, is there a web page that describes why this hazard exists? I'm sure it's very technical, so the more layman the better. Of course, I will take what I can get. Thanks again.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2012-02-18 00:58 +1100 |
| Message-ID | <9q74ofF39lU1@mid.individual.net> |
| In reply to | #2650 |
AndyHancock wrote > AndyHancock <andymhanc...@gmail.com> wrote >> Rod Speed <rod.speed....@gmail.com> wrote >>> AndyHancock wrote >>>> Apparently, if you've booted off of the clone drive once, you >>>> no longer run the risk of making both drives unbootable if you >>>> happen to have both drives connected during boot time. >>> Yes, that is correct. >>>> ...would...booting off the clone when it is in the eSATA >>>> enclosure qualifies as having booted once? >>> Yes it does. >>>> What about if you boot once when the clone is in the eSATA >>>> enclosure, then boot a 2nd time when it is in the laptop...during >>>> that 2nd time, would the clone be already out of the danger zone? >>> Yes it is. >>>> If so, it means that I can have another bootable HDD in the eSATA >>>> enclosure (for example, the source HDD) during bootup. >>> Not during the first boot of the clone after the clone has been created. >> Thanks for clarifying the danger, Rod. > Actually, I have one more variation on the above scenarios that I'd > appreciate your expertise on. > Say one of the two HDDs acts as a target for weekly cloning of the other HDD, It doesnt really make a lot of sense to clone for backup like that. It makes a lot more sense to backup instead of clone, both because of that is much quicker than cloning with incremental backups and because you dont have this problem with the first boot of the clone after the clone has been done. > and that both HDDs undergone their virgin booting. You've mangled that considerably. The only time that virgin booting config matters is when booting the clone. You dont actually boot the clone if you are cloning for backujp, you just keep booting the source. When you boot the source, it doesnt matter that the clone is visible at the time the source is booted after the clone has been done. The only thing you have to be careful about is booting the clone for the first time with the source visible to the clone. > Say the weekly cloning consists only of cloning the C-drive (partition > 2 of Toshiba's 4-partition setup). Does cloning only partition 2 put the > target HDD back into its virgin state of never having been booted from > before, thus re-introducing the problem of making both HDDs unbootable > if both are connected during a bootup? No, there is never a problem with booting the source. The problem only every arises when booting the clone for the first time. When you boot the clone for the first time, the source must not be visible. > As well, is there a web page that describes why this hazard exists? Likely there is, but I havent looked for one. > I'm sure it's very technical, It isnt actually. > so the more layman the better. Of course, I will take what I can get. I havent had a look at what is available. > Thanks again. No problem.
[toc] | [prev] | [next] | [standalone]
| From | AndyHancock <andymhancock@gmail.com> |
|---|---|
| Date | 2012-02-19 15:04 -0800 |
| Message-ID | <ddda83aa-70ae-492e-9de8-c70ad2018583@w9g2000vbv.googlegroups.com> |
| In reply to | #2652 |
On Feb 17, 8:58 am, "Rod Speed" <rod.speed....@gmail.com> wrote: > AndyHancock wrote >> AndyHancock <andymhanc...@gmail.com> wrote >>> Rod Speed <rod.speed....@gmail.com> wrote >>>> AndyHancock wrote >>>>> What about if you boot once when the clone is in the eSATA >>>>> enclosure, then boot a 2nd time when it is in the laptop...during >>>>> that 2nd time, would the clone be already out of the danger zone? >>>> >>>> Yes it is. >>>> >>>>> If so, it means that I can have another bootable HDD in the eSATA >>>>> enclosure (for example, the source HDD) during bootup. >>>> >>>> Not during the first boot of the clone after the clone has been created. >> >> Actually, I have one more variation on the above scenarios that I'd >> appreciate your expertise on. >> Say one of the two HDDs acts as a target for weekly cloning of the other HDD, > > It doesnt really make a lot of sense to clone for backup like that. > > It makes a lot more sense to backup instead of clone, both > because of that is much quicker than cloning with incremental > backups and because you dont have this problem with the > first boot of the clone after the clone has been done. I intend to explore that avenue...for now, I just want to be able to drop in a replacement if the source HDD gets so bad that any restored image is not trustworthy (if the source HDD even works, that is). >> and that both HDDs undergone their virgin booting. > > You've mangled that considerably. The only time that virgin booting > config matters is when booting the clone. You dont actually boot the > clone if you are cloning for backujp, you just keep booting the source. Perhaps I did mangle it...but the risk factors I'm being careful about are that in order to control the boot sequence, I have to enter the BIOS. It's easy to miss the window of opportunity for doing that. Granted, I expect the typical BIOS setup to put the internal HDD ahead of an external eSATA drive, but I have no experience on which I can conclude that this is the case most of the time (in fact, *all* of the time would be what I'm after for something with such a huge consequence). I can't plug in the clone HDD (in eSATA enclosure) after the booting because it is not hot-swappable. So far as I've tried, I haven't found a way to make it visible to the laptop other than to have it connected during boot time. This means I have to remove the source HDD, unless I want to take my chances and catch the time window for entering the BIOS. Most of the time, I make it, but not always. Also, I've read that making clones and backups aren't much good unless they are tested. So I will have to test the clone to ensure that it boots. It's what I do now, but I'm seeking a more convenient way of preventing the clone from getting a wrong drive letter. > When you boot the source, it doesnt matter that the clone is visible > at the time the source is booted after the clone has been done. > > The only thing you have to be careful about is booting the > clone for the first time with the source visible to the clone. Understood, and thanks for that clarification. My challenge above is to ensure that I boot from the source. >> Say the weekly cloning consists only of cloning the C-drive (partition >> 2 of Toshiba's 4-partition setup). Does cloning only partition 2 put the >> target HDD back into its virgin state of never having been booted from >> before, thus re-introducing the problem of making both HDDs unbootable >> if both are connected during a bootup? > > No, there is never a problem with booting the source. The problem > only every arises when booting the clone for the first time. When > you boot the clone for the first time, the source must not be visible. > >> As well, is there a web page that describes why this hazard exists? > > Likely there is, but I havent looked for one. > >> I'm sure it's very technical, > > It isnt actually. > >> so the more layman the better. Of course, I will take what I can get. Someone posted this on another forum: http://www.goodells.net/multiboot/partsigs.shtml The first section, "Fixing Windows 2000/XP Drive Letters" I found it quite helpful.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2012-02-20 10:55 +1100 |
| Message-ID | <9qdgevFhpgU1@mid.individual.net> |
| In reply to | #2654 |
AndyHancock wrote > Rod Speed <rod.speed....@gmail.com> wrote >> AndyHancock wrote >>> AndyHancock <andymhanc...@gmail.com> wrote >>>> Rod Speed <rod.speed....@gmail.com> wrote >>>>> AndyHancock wrote >>>>>> What about if you boot once when the clone is in the eSATA >>>>>> enclosure, then boot a 2nd time when it is in the laptop...during >>>>>> that 2nd time, would the clone be already out of the danger zone? >>>>> Yes it is. >>>>>> If so, it means that I can have another bootable HDD in the eSATA >>>>>> enclosure (for example, the source HDD) during bootup. >>>>> Not during the first boot of the clone after the clone has been created. >>> Actually, I have one more variation on the above scenarios that I'd >>> appreciate your expertise on. >>> Say one of the two HDDs acts as a target for weekly cloning of the >>> other HDD, >> It doesnt really make a lot of sense to clone for backup like that. >> It makes a lot more sense to backup instead of clone, both >> because of that is much quicker than cloning with incremental >> backups and because you dont have this problem with the >> first boot of the clone after the clone has been done. > I intend to explore that avenue...for now, I just want to be able to > drop in a replacement if the source HDD gets so bad that any restored > image is not trustworthy (if the source HDD even works, that is). OK. >>> and that both HDDs undergone their virgin booting. >> You've mangled that considerably. The only time that virgin booting >> config matters is when booting the clone. You dont actually boot the >> clone if you are cloning for backujp, you just keep booting the source. > Perhaps I did mangle it...but the risk factors I'm being careful about > are that in order to control the boot sequence, I have to enter the > BIOS. It's easy to miss the window of opportunity for doing that. > Granted, I expect the typical BIOS setup to put the internal HDD ahead > of an external eSATA drive, but I have no experience on which I can > conclude that this is the case most of the time (in fact, *all* of the time > would be what I'm after for something with such a huge consequence). It isnt really that huge a consequence. The worst that can happen is that you do somehow manage to boot the clone without intending to do that, and the worst that can do is end up with a clone that wont boot without the source drive being visible to the clone when booting. The only thing you have to do then is to just reclone the source again. Just a nuisance in the very unlikely even that you do manage to boot the clone accidentally somehow. > I can't plug in the clone HDD (in eSATA enclosure) after > the booting because it is not hot-swappable. So far as > I've tried, I haven't found a way to make it visible to the > laptop other than to have it connected during boot time. You can usually make it visible just by gettng the system to rescan for devices in the device manageer. > This means I have to remove the source HDD, unless I want to take my chances and > catch the time window for entering the BIOS. Most of the time, I make it, but not always. You dont have to remove the source HDD, you can just rely on the system to boot the source HDD and not the clone, even if you do leave the clone connected to the system on the boot after the clone has been done. > Also, I've read that making clones and backups > aren't much good unless they are tested. You do have to test that the clone is bootable when you first do a clone. But you dont have to boot the clone every time you do a weekly reclone for backup. > So I will have to test the clone to ensure that it boots. Not every time you reclone for backup, every week. > It's what I do now, but I'm seeking a more convenient way > of preventing the clone from getting a wrong drive letter. Just dont bother to boot the clone after every reclone for backup. If you are really paranoid, you clould try booting the clone every couple of months, but I wouldnt bother personally. >> When you boot the source, it doesnt matter that the clone is visible >> at the time the source is booted after the clone has been done. >> The only thing you have to be careful about is booting the >> clone for the first time with the source visible to the clone. > Understood, and thanks for that clarification. My > challenge above is to ensure that I boot from the source. I'd just rely on the bios to not change the boot drive until you change that manually. The worst that can happen if it does manage to change the drive it boots off without you telling it to do that is that you have to reclone again. Just a nuisance. >>> Say the weekly cloning consists only of cloning the C-drive >>> (partition 2 of Toshiba's 4-partition setup). Does cloning only >>> partition 2 put the target HDD back into its virgin state of never >>> having been booted from before, thus re-introducing the problem of >>> making both HDDs unbootable if both are connected during a bootup? >> No, there is never a problem with booting the source. The problem >> only every arises when booting the clone for the first time. When >> you boot the clone for the first time, the source must not be visible. >>> As well, is there a web page that describes why this hazard exists? >> Likely there is, but I havent looked for one. >>> I'm sure it's very technical, >> It isnt actually. >>> so the more layman the better. Of course, I will take what I can get. > Someone posted this on another forum: > http://www.goodells.net/multiboot/partsigs.shtml > The first section,"Fixing Windows 2000/XP Drive Letters" > I found it quite helpful. The problem isnt actually with drive letters. If you boot the clone after a clone has been done with the source still visible, it boots fine with the drive letters the way you expect them to be. The problem is that once its booted, you will find that if you remove the source drive, you cant boot anymore. The reason you cant is because the boot of the clone uses files on the source drive and they arent visible anymore.
[toc] | [prev] | [next] | [standalone]
| From | AndyHancock <andymhancock@gmail.com> |
|---|---|
| Date | 2012-02-19 21:27 -0800 |
| Message-ID | <8ec01df6-dff3-44f0-9ef6-f93066330784@t30g2000vbx.googlegroups.com> |
| In reply to | #2655 |
On Feb 19, 6:55 pm, "Rod Speed" <rod.speed....@gmail.com> wrote: > AndyHancock wrote >> ...the risk factors I'm being careful about are that in order to >> control the boot sequence, I have to enter the BIOS. It's easy to >> miss the window of opportunity for doing that. Granted, I expect >> the typical BIOS setup to put the internal HDD ahead of an external >> eSATA drive, but I have no experience on which I can conclude that >> this is the case most of the time (in fact, *all* of the time would >> be what I'm after for something with such a huge consequence). > > It isnt really that huge a consequence. The worst that can happen is > that you do somehow manage to boot the clone without intending to do > that, and the worst that can do is end up with a clone that wont > boot without the source drive being visible to the clone when > booting. > > The only thing you have to do then is to just reclone the source > again. > > Just a nuisance in the very unlikely even that you do manage to boot > the clone accidentally somehow. So based on that, I assume that the C-drive content on the source HDD won't be modified during the clone bootup in any consequential way? By consequential, I mean in ways that could mess up any future bootups from the source HDD. The reason why this question comes to mind is that, according to the webpage I cited, the registry of the clone specifies paths to the C- drive. I never really got familiar with the registry, since there's always warnings that mistakes can put your system into a coma. So I'm not sure what is done with the C-drive paths in the registry during bootup. >> I can't plug in the clone HDD (in eSATA enclosure) after the >> booting because it is not hot-swappable. So far as I've tried, I >> haven't found a way to make it visible to the laptop other than to >> have it connected during boot time. > > You can usually make it visible just by gettng the system to rescan > for devices in the device manageer. That was one of the first things I tried when I was first attempted cloning to the Toshiba replacement HDD (which was placed into the eSATA housing). Did all sorts of variations until there was nothing left to try. It didn't work then, but it works now. I wonder if it has anything to do with the fact that all 4 partitions are present now. I wouldn't expect so, but heck, I'm still getting to know the nuances. I'm pretty sure that I also tried plugging in the USB cables before the eSATA cable, and vice-versa. This time, when it works, it was the USB cables before eSATA cables. I suspect that the USB cables are for power (documentation for the enclosure is skimpy). Anyway, since I don't know what caused the failure before, I'm hopeful but not confident that rescanning will make the auxiliary HDD visible in the future. Fingers crossed. >> This means I have to remove the source HDD, unless I want to take >> my chances and catch the time window for entering the BIOS. Most >> of the time, I make it, but not always. > > You dont have to remove the source HDD, you can just rely on the > system to boot the source HDD and not the clone, even if you do > leave the clone connected to the system on the boot after the clone > has been done. From my limited experience with arranging the order of boot devices, it seems that this is controlled in the boot order in the BIOS. What I wasn't sure about were the rules or heuristics determining the boot order when a new device is introduced into the system. The auxiliary HDD disappears from the list when it isn't connected, so every time it is connected, it might look like a new device. >> Also, I've read that making clones and backups aren't much good >> unless they are tested. > > You do have to test that the clone is bootable when you first do a > clone. > > But you dont have to boot the clone every time you do a weekly > reclone for backup. > >> So I will have to test the clone to ensure that it boots. > > Not every time you reclone for backup, every week. > >> It's what I do now, but I'm seeking a more convenient way of >> preventing the clone from getting a wrong drive letter. > > Just dont bother to boot the clone after every reclone for backup. > > If you are really paranoid, you clould try booting the clone every > couple of months, but I wouldnt bother personally. Well, it *is* a pain...it's just that I've read accounts of what can happen when someone didn't. He found that his safety net wasn't there after he found that he needed it. >> My challenge above is to ensure that I boot from the source. > > I'd just rely on the bios to not change the boot drive until you > change that manually. That's exactly the unknown from my perspective (which admittedly isn't one of an expert). Since the auxiliary HDD disappears from the boot- order list, there is no boot order for the bios to maintain, at least as it pertains to the auxiliary HDD. So when I plug it in and boot, I'm not sure that the internal HDD will have precedence in the boot order. If Disk Management's rescan works consistently, I don't have to worry about connecting the auxiliary drive prior to booting. > The worst that can happen if it does manage to change the drive it > boots off without you telling it to do that is that you have to > reclone again. Just a nuisance. True. As I mentioned, I just wasn't sure whether the C-drive content would be changed in any consequential way by the booting of the clone. I'm assuming from your answer that it wouldn't be. >>>> As well, is there a web page that describes why this hazard >>>> exists? >> Someone posted this on another forum: >> http://www.goodells.net/multiboot/partsigs.shtml The first >> section,"Fixing Windows 2000/XP Drive Letters" I found it quite >> helpful. > > The problem isnt actually with drive letters. If you boot the clone > after a clone has been done with the source still visible, it boots > fine with the drive letters the way you expect them to be. The > problem is that once its booted, you will find that if you remove > the source drive, you cant boot anymore. The reason you cant is > because the boot of the clone uses files on the source drive and > they arent visible anymore. I guess it is a matter of perspective. The clone's registry info is meant to point at its own drive. It will work if it points to the source partition, but that's not how things were meant to be set up. This dependence creates a very nonrobust situation. Plus, as I said, I'm not familiar with what registry things might point to the source HDD, and I'm not familiar with whether the booting process actually writes to the locations being pointed to. I'm assuming from your answers that there is no risk of the clone-booting process doing writes to the source HDD's C-drive in a way that would creates problems for the booting of the source HDD. Thanks again for the added insight.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2012-02-20 20:12 +1100 |
| Message-ID | <9qeh3hFau0U1@mid.individual.net> |
| In reply to | #2656 |
AndyHancock wrote > Rod Speed <rod.speed....@gmail.com> wrote >> AndyHancock wrote >>> ...the risk factors I'm being careful about are that in order to >>> control the boot sequence, I have to enter the BIOS. It's easy to >>> miss the window of opportunity for doing that. Granted, I expect >>> the typical BIOS setup to put the internal HDD ahead of an external >>> eSATA drive, but I have no experience on which I can conclude that >>> this is the case most of the time (in fact, *all* of the time would >>> be what I'm after for something with such a huge consequence). >> It isnt really that huge a consequence. The worst that can happen is >> that you do somehow manage to boot the clone without intending to >> do that, and the worst that can do is end up with a clone that wont >> boot without the source drive being visible to the clone when booting. >> The only thing you have to do then is to just reclone the source again. >> Just a nuisance in the very unlikely even that you do manage to boot >> the clone accidentally somehow. > So based on that, I assume that the C-drive content on the source HDD > won't be modified during the clone bootup in any consequential way? Correct. > By consequential, I mean in ways that could mess up any future bootups > from the source HDD. Correct. > The reason why this question comes to mind is that, according to the > webpage I cited, the registry of the clone specifies paths to the C- drive. Yes, but the registry on the source drive wont be affected even if you boot the clone with the source visible. > never really got familiar with the registry, since there's always > warnings that mistakes can put your system into a coma. All they are really saying when they say that is that any manual changes need to be done carefully. > So I'm not sure what is done with the C-drive paths in the registry during bootup. Nothing with the registry on the source drive when booting the clone even with the source drive visible. >>> I can't plug in the clone HDD (in eSATA enclosure) after the >>> booting because it is not hot-swappable. So far as I've tried, >>> I haven't found a way to make it visible to the laptop other >>> than to have it connected during boot time. >> You can usually make it visible just by gettng the system >> to rescan for devices in the device manageer. > That was one of the first things I tried when I was first attempted > cloning to the Toshiba replacement HDD (which was placed into > the eSATA housing). Did all sorts of variations until there was > nothing left to try. It didn't work then, but it works now. It can get a bit confused if you dont try things in the right order. You really need to reboot with the drive not connected between trys. > I wonder if it has anything to do with the fact that all 4 partitions are present now. Nope. > I wouldn't expect so, but heck, I'm still getting to know the nuances. > I'm pretty sure that I also tried plugging in the USB > cables before the eSATA cable, and vice-versa. You shouldnt need to have them all connected, just the ones you want to use. Likely thats what confused it. > This time, when it works, it was the USB cables before eSATA cables. > I suspect that the USB cables are for power Nope, not with a 3.5" drive. > (documentation for the enclosure is skimpy). Anyway, > since I don't know what caused the failure before, I'm > hopeful but not confident that rescanning will make the > auxiliary HDD visible in the future. Fingers crossed. Should do, it shouldnt be variable in the sense that the same sequence should work reliably. >>> This means I have to remove the source HDD, unless I want >>> to take my chances and catch the time window for entering >>> the BIOS. Most of the time, I make it, but not always. >> You dont have to remove the source HDD, you can just rely on the >> system to boot the source HDD and not the clone, even if you do >> leave the clone connected to the system on the boot after the clone >> has been done. > From my limited experience with arranging the order of boot devices, > it seems that this is controlled in the boot order in the BIOS. Correct. > What I wasn't sure about were the rules or heuristics determining > the boot order when a new device is introduced into the system. It wont normally go to the head of the boot order with an external drive. On the other hand, if you specify the external drive at the top of the boot order, it should fall thru to booting the internal drive when the external drive isnt there, and still boot the external drive when you later add an external drive and reboot. > The auxiliary HDD disappears from the list when it isn't connected, > so every time it is connected, it might look like a new device. Yes, but it shouldnt got to the head of the boot order unless you specify it as the first one to boot, and then later reboot with the external visible to the system. That isnt a new drive, its just the external being visible again at boot time. >>> Also, I've read that making clones and backups aren't much good >>> unless they are tested. >> You do have to test that the clone is bootable when you first do a clone. >> But you dont have to boot the clone every time you do a weekly reclone for backup. >>> So I will have to test the clone to ensure that it boots. >> Not every time you reclone for backup, every week. >>> It's what I do now, but I'm seeking a more convenient way of >>> preventing the clone from getting a wrong drive letter. >> Just dont bother to boot the clone after every reclone for backup. >> If you are really paranoid, you clould try booting the clone every >> couple of months, but I wouldnt bother personally. > Well, it *is* a pain...it's just that I've read accounts of what can > happen when someone didn't. He found that his safety net wasn't there > after he found that he needed it. Yes, but thats checking that it is bootable, not doing that after every clone. >>> My challenge above is to ensure that I boot from the source. >> I'd just rely on the bios to not change the boot drive until you >> change that manually. > That's exactly the unknown from my perspective (which admittedly isn't > one of an expert). Since the auxiliary HDD disappears from the boot- > order list, there is no boot order for the bios to maintain, at least as it > pertains to the auxiliary HDD. So when I plug it in and boot, I'm not sure > that the internal HDD will have precedence in the boot order. Its trivial to test. > If Disk Management's rescan works consistently, I don't have > to worry about connecting the auxiliary drive prior to booting. Correct. >> The worst that can happen if it does manage to change >> the drive it boots off without you telling it to do that is >> that you have to reclone again. Just a nuisance. > True. As I mentioned, I just wasn't sure whether the C-drive content > would be changed in any consequential way by the booting of the > clone. I'm assuming from your answer that it wouldn't be. Correct, it wont be. >>>>> As well, is there a web page that describes why this hazard exists? >>> Someone posted this on another forum: >>> http://www.goodells.net/multiboot/partsigs.shtml >>> The first section,"Fixing Windows 2000/XP Drive Letters" I found it quite helpful. >> The problem isnt actually with drive letters. If you boot the clone >> after a clone has been done with the source still visible, it boots >> fine with the drive letters the way you expect them to be. The >> problem is that once its booted, you will find that if you remove >> the source drive, you cant boot anymore. The reason you cant is >> because the boot of the clone uses files on the source drive and >> they arent visible anymore. > I guess it is a matter of perspective. The clone's registry info > is meant to point at its own drive. It will work if it points to the > source partition, but that's not how things were meant to be set up. The problem with the boot config when you boot the clone for the first time with the source visible doesnt involve the registry. Thats part of the very early part of the boot phase, before the registry is used. > This dependence creates a very nonrobust situation. Plus, as I said, > I'm not familiar with what registry things might point to the source > HDD, and I'm not familiar with whether the booting process actually > writes to the locations being pointed to. I'm assuming from your > answers that there is no risk of the clone-booting process doing > writes to the source HDD's C-drive in a way that would creates > problems for the booting of the source HDD. Correct. > Thanks again for the added insight. No problem, thats what these technical groups are for.
[toc] | [prev] | [next] | [standalone]
| From | AndyHancock <andymhancock@gmail.com> |
|---|---|
| Date | 2012-02-20 22:50 -0800 |
| Message-ID | <78422766-c9c8-4f62-85c7-3043cdb4ded2@gi10g2000vbb.googlegroups.com> |
| In reply to | #2657 |
On Feb 20, 4:12 am, "Rod Speed" <rod.speed....@gmail.com> wrote: > AndyHancock wrote >> Rod Speed <rod.speed....@gmail.com> wrote >>> ...The worst that can happen is that you do somehow manage to boot >>> the clone without intending to do that, and the worst that can do >>> is end up with a clone that wont boot without the source drive >>> being visible to the clone when booting. >>> >>> The only thing you have to do then is to just reclone the source >>> again. Just a nuisance in the very unlikely even that you do >>> manage to boot the clone accidentally somehow. >> >> So based on that, I assume that the C-drive content on the source >> HDD won't be modified during the clone bootup in any consequential >> way? By consequential, I mean in ways that could mess up any >> future bootups from the source HDD. > > Correct. > >> The reason why this question comes to mind is that, according to >> the webpage I cited, the registry of the clone specifies paths to >> the C- drive. > > Yes, but the registry on the source drive wont be affected even if > you boot the clone with the source visible. > >> ...I'm not sure what is done with the C-drive paths in the registry >> during bootup. > > Nothing with the registry on the source drive when booting the clone > even with the source drive visible. Understood. The registry on the source HDD isn't changed. Would you know if some of the registry entries (duplicated in the source and target HDDs) pointing to the C-drive are file paths that are written to? >>>> I can't plug in the clone HDD (in eSATA enclosure) after the >>>> booting because it is not hot-swappable. So far as I've tried, I >>>> haven't found a way to make it visible to the laptop other than >>>> to have it connected during boot time. >>> You can usually make it visible just by gettng the system to >>> rescan for devices in the device manageer. >> That was one of the first things I tried when I was first attempted >> cloning to the Toshiba replacement HDD (which was placed into the >> eSATA housing). Did all sorts of variations until there was >> nothing left to try. It didn't work then, but it works now. > > It can get a bit confused if you dont try things in the right order. > > You really need to reboot with the drive not connected between trys. Now that's a pain. >> I'm pretty sure that I also tried plugging in the USB cables before >> the eSATA cable, and vice-versa. > > You shouldnt need to have them all connected, just the ones you want > to use. Likely thats what confused it. > >> This time, when it works, it was the USB cables before eSATA >> cables. I suspect that the USB cables are for power > > Nope, not with a 3.5" drive. The drive doesn't light up or make any noises without the USB cables. It also doesn't show up on the laptop, even if connected via eSATA (only) at boot time. I'm sure the USB cables are for power -- I just wasn't sure that's all they're for. Nothing shows up in the USB devices, but that's no guarantee that they're not using the cables for more than just power. After all, an iPod Touch doesn't show up as a USB device either. >> (documentation for the enclosure is skimpy). Anyway, since I don't >> know what caused the failure before, I'm hopeful but not confident >> that rescanning will make the auxiliary HDD visible in the future. >> Fingers crossed. > > Should do, it shouldnt be variable in the sense that the same > sequence should work reliably. I would hope so, but since the same sequence didn't make the auxiliary HDD visible after a rescan, it might be the system getting confused, as you suggested. >>> Just dont bother to boot the clone after every reclone for backup. >>> If you are really paranoid, you clould try booting the clone every >>> couple of months, but I wouldnt bother personally. >> >> Well, it *is* a pain...it's just that I've read accounts of what >> can happen when someone didn't. He found that his safety net >> wasn't there after he found that he needed it. > > Yes, but thats checking that it is bootable, not doing that after > every clone. Alright, I'll keep that in mind. Thanks. >>>> My challenge above is to ensure that I boot from the source. >>> >>> I'd just rely on the bios to not change the boot drive until you >>> change that manually. >> >> That's exactly the unknown from my perspective (which admittedly >> isn't one of an expert). Since the auxiliary HDD disappears from >> the boot- order list, there is no boot order for the bios to >> maintain, at least as it pertains to the auxiliary HDD. So when I >> plug it in and boot, I'm not sure that the internal HDD will have >> precedence in the boot order. > > Its trivial to test. Here's the result from my test. The auxiliary HDD is listed last on the boot list. If I move it up to the top, it is remembered after I shut down. I can disconnect the auxiliary HDD and reconnect it, and it will still remain at the top. However, if I boot once without the auxiliary HDD, it will have lost its place in the boot list. Next time I reconnect and boot, it will show up last again. Thanks for the push to characterize that. >>>>>> ...is there a web page that describes why this hazard >>>>>> exists? >>>> >>>> Someone posted this on another forum: >>>> http://www.goodells.net/multiboot/partsigs.shtml The first >>>> section,"Fixing Windows 2000/XP Drive Letters" I found it quite >>>> helpful. >>> >>> The problem isnt actually with drive letters. If you boot the >>> clone after a clone has been done with the source still visible, >>> it boots fine with the drive letters the way you expect them to >>> be. The problem is that once its booted, you will find that if you >>> remove the source drive, you cant boot anymore. The reason you >>> cant is because the boot of the clone uses files on the source >>> drive and they arent visible anymore. >> >> I guess it is a matter of perspective. The clone's registry info >> is meant to point at its own drive. It will work if it points to >> the source partition, but that's not how things were meant to be >> set up. > > The problem with the boot config when you boot the clone for the > first time with the source visible doesnt involve the registry. > Thats part of the very early part of the boot phase, before the > registry is used. OK, looks like either the website didn't tell the whole story, or I didn't quit understand it. I thought it meant that there are C-drive paths in the cloned registry, so when someone takes away the source C- drive, then the corresponding files won't be available to the clone. >> I'm assuming from your answers that there is no risk of the >> clone-booting process doing writes to the source HDD's C-drive in a >> way that would creates problems for the booting of the source HDD. > > Correct.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2012-02-21 20:20 +1100 |
| Message-ID | <9qh5uqF230U1@mid.individual.net> |
| In reply to | #2658 |
AndyHancock wrote > Rod Speed <rod.speed....@gmail.com> wrote >> AndyHancock wrote >>> Rod Speed <rod.speed....@gmail.com> wrote >>>> ...The worst that can happen is that you do somehow manage to boot >>>> the clone without intending to do that, and the worst that can do >>>> is end up with a clone that wont boot without the source drive >>>> being visible to the clone when booting. >>>> The only thing you have to do then is to just reclone the source >>>> again. Just a nuisance in the very unlikely even that you do >>>> manage to boot the clone accidentally somehow. >>> So based on that, I assume that the C-drive content on the source >>> HDD won't be modified during the clone bootup in any consequential >>> way? By consequential, I mean in ways that could mess up any >>> future bootups from the source HDD. >> Correct. >>> The reason why this question comes to mind is that, according to >>> the webpage I cited, the registry of the clone specifies paths to >>> the C- drive. >> Yes, but the registry on the source drive wont be affected even if >> you boot the clone with the source visible. >>> ...I'm not sure what is done with the C-drive paths in the registry during bootup. >> Nothing with the registry on the source drive when booting the clone >> even with the source drive visible. > Understood. The registry on the source HDD isn't changed. > Would you know if some of the registry entries (duplicated in the source > and target HDDs) pointing to the C-drive are file paths that are written to? Dont understand the question. >>>>> I can't plug in the clone HDD (in eSATA enclosure) after the >>>>> booting because it is not hot-swappable. So far as I've tried, I >>>>> haven't found a way to make it visible to the laptop other than >>>>> to have it connected during boot time. >>>> You can usually make it visible just by gettng the system to >>>> rescan for devices in the device manageer. >>> That was one of the first things I tried when I was first attempted >>> cloning to the Toshiba replacement HDD (which was placed into the >>> eSATA housing). Did all sorts of variations until there was >>> nothing left to try. It didn't work then, but it works now. >> It can get a bit confused if you dont try things in the right order. >> You really need to reboot with the drive not connected between trys. > Now that's a pain. Yep. >>> I'm pretty sure that I also tried plugging in the USB cables before >>> the eSATA cable, and vice-versa. >> You shouldnt need to have them all connected, just the ones you want >> to use. Likely thats what confused it. >>> This time, when it works, it was the USB cables before eSATA >>> cables. I suspect that the USB cables are for power >> Nope, not with a 3.5" drive. > The drive doesn't light up or make any noises without the USB cables. > It also doesn't show up on the laptop, even if connected via eSATA > (only) at boot time. I'm sure the USB cables are for power -- Thats unlikely with a 3.5" drive. > I just wasn't sure that's all they're for. Nothing shows up in the USB > devices, but that's no guarantee that they're not using the cables for > more than just power. After all, an iPod Touch doesn't show up as a > USB device either. >>> (documentation for the enclosure is skimpy). Anyway, since I don't >>> know what caused the failure before, I'm hopeful but not confident >>> that rescanning will make the auxiliary HDD visible in the future. >>> Fingers crossed. >> Should do, it shouldnt be variable in the sense that the same >> sequence should work reliably. > I would hope so, but since the same sequence didn't make the auxiliary HDD > visible after a rescan, it might be the system getting confused, as you suggested. >>>> Just dont bother to boot the clone after every reclone for backup. >>>> If you are really paranoid, you clould try booting the clone every >>>> couple of months, but I wouldnt bother personally. >>> Well, it *is* a pain...it's just that I've read accounts of what >>> can happen when someone didn't. He found that his safety net >>> wasn't there after he found that he needed it. >> Yes, but thats checking that it is bootable, not doing that after every clone. > Alright, I'll keep that in mind. Thanks. >>>>> My challenge above is to ensure that I boot from the source. >>>> I'd just rely on the bios to not change the boot drive until you >>>> change that manually. >>> That's exactly the unknown from my perspective (which admittedly >>> isn't one of an expert). Since the auxiliary HDD disappears from >>> the boot- order list, there is no boot order for the bios to >>> maintain, at least as it pertains to the auxiliary HDD. So when I >>> plug it in and boot, I'm not sure that the internal HDD will have >>> precedence in the boot order. >> Its trivial to test. > Here's the result from my test. The auxiliary HDD is listed last on > the boot list. If I move it up to the top, it is remembered after I > shut down. I can disconnect the auxiliary HDD and reconnect it, and > it will still remain at the top. However, if I boot once without the > auxiliary HDD, it will have lost its place in the boot list. Next > time I reconnect and boot, it will show up last again. Thanks for the > push to characterize that. >>>>>>> ...is there a web page that describes why this hazard >>>>>>> exists? >>>>> Someone posted this on another forum: >>>>> http://www.goodells.net/multiboot/partsigs.shtml >>>>> The first section,"Fixing Windows 2000/XP Drive Letters" I found it quite helpful. >>>> The problem isnt actually with drive letters. If you boot the >>>> clone after a clone has been done with the source still visible, >>>> it boots fine with the drive letters the way you expect them to >>>> be. The problem is that once its booted, you will find that if you >>>> remove the source drive, you cant boot anymore. The reason you >>>> cant is because the boot of the clone uses files on the source >>>> drive and they arent visible anymore. >>> I guess it is a matter of perspective. The clone's registry info >>> is meant to point at its own drive. It will work if it points to the >>> source partition, but that's not how things were meant to be set up. >> The problem with the boot config when you boot the clone for the >> first time with the source visible doesnt involve the registry. >> Thats part of the very early part of the boot phase, before the >> registry is used. > OK, looks like either the website didn't tell the whole story, Thats correct, it doesnt, particularly with the early boot phase before the registry is even relevant. > or I didn't quit understand it. I thought it meant that there are C-drive > paths in the cloned registry, so when someone takes away the source > C-drive, then the corresponding files won't be available to the clone. >>> I'm assuming from your answers that there is no risk of the >>> clone-booting process doing writes to the source HDD's C-drive in a >>> way that would creates problems for the booting of the source HDD. >> Correct.
[toc] | [prev] | [next] | [standalone]
| From | AndyHancock <andymhancock@gmail.com> |
|---|---|
| Date | 2012-02-21 22:08 -0800 |
| Message-ID | <5059cb06-e80b-4c36-a212-d5eafa54d3d4@w1g2000vbg.googlegroups.com> |
| In reply to | #2659 |
On Feb 21, 4:20 am, "Rod Speed" <rod.speed....@gmail.com> wrote: > AndyHancock wrote >> Would you know if some of the registry entries (duplicated in the source >> and target HDDs) pointing to the C-drive are file paths that are written to? > > Dont understand the question. In the post that I last responded to, you mentioned twice that booting off the clone won't affect the registry on the source HDD. You also confirmed twice (rather than explicitly mentioning) that booting the clone won't change the source C-drive content in a consequential way i.e. by affecting booting of the source. The latter is a little different from the former. I wonder if you meant the same thing as the former, though. It's easy to overlook the nuance if you're replying quickly (not that you necessarily are!), especially if you're just confirming or denying rather than writing out the statement. Why do I want to confirm this? Because the registry on the clone contains paths to the source C-drive. I'm not sure if the booting process uses such file paths as targets for writing. >> The drive doesn't light up or make any noises without the USB cables. >> It also doesn't show up on the laptop, even if connected via eSATA >> (only) at boot time. I'm sure the USB cables are for power -- > > Thats unlikely with a 3.5" drive. It might be the enclosure. All I know is that without the pair of USB connectors plugged in, the enclosure shows no sign of life. >>> The problem with the boot config when you boot the clone for the >>> first time with the source visible doesnt involve the registry. >>> Thats part of the very early part of the boot phase, before the >>> registry is used. >> >> OK, looks like either the website didn't tell the whole story, > > Thats correct, it doesnt, particularly with the early boot phase before > the registry is even relevant. OK, a bit more rampup required on my part. Thanks again.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2012-02-22 19:34 +1100 |
| Message-ID | <9qjnklFqeU1@mid.individual.net> |
| In reply to | #2660 |
AndyHancock wrote > Rod Speed <rod.speed....@gmail.com> wrote >> AndyHancock wrote >>> Would you know if some of the registry entries >>> (duplicated in the source and target HDDs) pointing >>> to the C-drive are file paths that are written to? >> Dont understand the question. > In the post that I last responded to, you mentioned twice that > booting off the clone won't affect the registry on the source HDD. Yes. > You also confirmed twice (rather than explicitly mentioning) > that booting the clone won't change the source C-drive content > in a consequential way i.e. by affecting booting of the source. Yes. > The latter is a little different from the former. Not really. > I wonder if you meant the same thing as the former, though. Yes I did. > It's easy to overlook the nuance if you're replying quickly > (not that you necessarily are!), especially if you're just > confirming or denying rather than writing out the statement. > Why do I want to confirm this? Because the registry > on the clone contains paths to the source C-drive. It contains paths to the C drive, yes. Not to the SOURCE C drive tho. > I'm not sure if the booting process uses such file paths as targets for writing. No it does not in the sense that they are paths to the SOURCE C drive. They are actually paths to the C drive on the clone. >>> The drive doesn't light up or make any noises without the USB cables. >>> It also doesn't show up on the laptop, even if connected via eSATA >>> (only) at boot time. I'm sure the USB cables are for power -- >> Thats unlikely with a 3.5" drive. > It might be the enclosure. Yes. Name it again so I dont have to look it up in the thread, if you did name it there. > All I know is that without the pair of USB connectors > plugged in, the enclosure shows no sign of life. Yeah, but that doesnt necessarily mean its getting power for the 3.5" drive from the USB cables. That would be unusual, USB cables dont have enough power for 3.5" drives. >>>> The problem with the boot config when you boot the clone for >>>> the first time with the source visible doesnt involve the registry. >>>> Thats part of the very early part of the boot phase, before the >>>> registry is used. >>> OK, looks like either the website didn't tell the whole story, >> Thats correct, it doesnt, particularly with the early boot phase >> before the registry is even relevant. > OK, a bit more rampup required on my part. Thanks again. No problem.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2012-02-23 05:09 +1100 |
| Message-ID | <9qkpjtFfqeU1@mid.individual.net> |
| In reply to | #2661 |
Rod Speed wrote: > AndyHancock wrote >> Rod Speed <rod.speed....@gmail.com> wrote >>> AndyHancock wrote >>>> The drive doesn't light up or make any noises without the USB >>>> cables. It also doesn't show up on the laptop, even if connected >>>> via eSATA (only) at boot time. I'm sure the USB cables are for >>>> power -- >>> Thats unlikely with a 3.5" drive. Whoops, my brain fart there. I was forgetting that its a laptop and that its a 2.5" drive, not a 3.5" drive. Ignore what I said there, its clearly using the USB cables for power.
[toc] | [prev] | [next] | [standalone]
| From | AndyHancock <andymhancock@gmail.com> |
|---|---|
| Date | 2012-02-22 20:26 -0800 |
| Message-ID | <5361493e-76ee-4c88-8cbb-b90768348e09@eb6g2000vbb.googlegroups.com> |
| In reply to | #2663 |
On Feb 22, 1:09 pm, "Rod Speed" <rod.speed....@gmail.com> wrote: > Rod Speed wrote: > > AndyHancock wrote > >> Rod Speed <rod.speed....@gmail.com> wrote > >>> AndyHancock wrote > >>>> The drive doesn't light up or make any noises without the USB > >>>> cables. It also doesn't show up on the laptop, even if connected > >>>> via eSATA (only) at boot time. I'm sure the USB cables are for > >>>> power -- > >>> Thats unlikely with a 3.5" drive. > > Whoops, my brain fart there. I was forgetting that its > a laptop and that its a 2.5" drive, not a 3.5" drive. > > Ignore what I said there, its clearly using the USB cables for power. I just looked it up...yes, it's 2.5". Thanks!
[toc] | [prev] | [next] | [standalone]
| From | AndyHancock <andymhancock@gmail.com> |
|---|---|
| Date | 2012-02-22 20:46 -0800 |
| Message-ID | <efaebcdd-1474-4050-9ff4-312d5b232115@v2g2000vbx.googlegroups.com> |
| In reply to | #2661 |
On Feb 22, 3:34 am, "Rod Speed" <rod.speed....@gmail.com> wrote: > AndyHancock wrote >> Rod Speed <rod.speed....@gmail.com> wrote >>> AndyHancock wrote >>>> Would you know if some of the registry entries (duplicated in the >>>> source and target HDDs) pointing to the C-drive are file paths >>>> that are written to? >>> Dont understand the question. >> In the post that I last responded to, you mentioned twice that >> booting off the clone won't affect the registry on the source HDD. >> You also confirmed twice (rather than explicitly mentioning) that >> booting the clone won't change the source C-drive content in a >> consequential way i.e. by affecting booting of the source. The >> latter is a little different from the former. > > Not really. > >> I wonder if you meant the same thing as the former, though. > > Yes I did. > >> It's easy to overlook the nuance if you're replying quickly (not >> that you necessarily are!), especially if you're just confirming or >> denying rather than writing out the statement. Why do I want to >> confirm this? Because the registry on the clone contains paths to >> the source C-drive. > > It contains paths to the C drive, yes. > > Not to the SOURCE C drive tho. > >> I'm not sure if the booting process uses such file paths as targets >> for writing. > > No it does not in the sense that they are paths to the SOURCE C > drive. > > They are actually paths to the C drive on the clone. I believe we were discussing why it isn't such a big disaster for the clone to do its virgin boot with the source HDD still visible. Basically, the clone can be remade. However, I was wondering if the process of booting the clone could lead to disk-writes to the source HDD. After all, the clone gets a drive letter other than C-drive, but its registry still contains paths to the C-drive file system (which is the source HDD). Does the boot process use the paths stored in its registry in any way that could result in a write to a file in one of those paths? This is not the same as whether the boot process writes to the registry in the source HDD, which is what I assumed you were talking about. For that matter, what if someone hypothetically booted off the clone and failed to notice it (not that I or anyone else would do that). Would the routine use of windows cause writes to files whose paths are contained in the registry? Some of those paths are paths to the C- drive.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2012-02-23 20:04 +1100 |
| Message-ID | <9qmdo6Fbe1U1@mid.individual.net> |
| In reply to | #2665 |
AndyHancock wrote > Rod Speed <rod.speed....@gmail.com> wrote >> AndyHancock wrote >>> Rod Speed <rod.speed....@gmail.com> wrote >>>> AndyHancock wrote >>>>> Would you know if some of the registry entries (duplicated in the >>>>> source and target HDDs) pointing to the C-drive are file paths >>>>> that are written to? >>>> Dont understand the question. >>> In the post that I last responded to, you mentioned twice that >>> booting off the clone won't affect the registry on the source HDD. >>> You also confirmed twice (rather than explicitly mentioning) that >>> booting the clone won't change the source C-drive content in a >>> consequential way i.e. by affecting booting of the source. The >>> latter is a little different from the former. >> Not really. >>> I wonder if you meant the same thing as the former, though. >> Yes I did. >>> It's easy to overlook the nuance if you're replying quickly (not >>> that you necessarily are!), especially if you're just confirming or >>> denying rather than writing out the statement. Why do I want to >>> confirm this? Because the registry on the clone contains paths to >>> the source C-drive. >> It contains paths to the C drive, yes. >> Not to the SOURCE C drive tho. >>> I'm not sure if the booting process uses such file paths as targets for writing. >> No it does not in the sense that they are paths to the SOURCE C drive. >> They are actually paths to the C drive on the clone. > I believe we were discussing why it isn't such a big disaster for > the clone to do its virgin boot with the source HDD still visible. > Basically, the clone can be remade. Yes. > However, I was wondering if the process of booting > the clone could lead to disk-writes to the source HDD. No they dont. > After all, the clone gets a drive letter other than C-drive, No it doesnt. The clone gets the drive letter C > but its registry still contains paths to the C-drive file system Yes. > (which is the source HDD). Nope. The clone becomes the C drive and so the registry entrys still point to the clone. > Does the boot process use the paths stored in its registry in any > way that could result in a write to a file in one of those paths? Yes, but since the clone gets the letter C, that doesnt affect the source. > This is not the same as whether the boot process writes to the registry in the source HDD, That only happens if you boot the source. > which is what I assumed you were talking about. > For that matter, what if someone hypothetically booted off the clone > and failed to notice it (not that I or anyone else would do that). Then if the source is visible on the first boot of the clone, you end up with a boot that is normal but you will find that if you then remove the source, and boot again, you cant boot anymore because the early boot phase uses files on the source which isnt there anymore, so the boot fails. > Would the routine use of windows cause writes > to files whose paths are contained in the registry? Yes. > Some of those paths are paths to the C- drive. Yes. But the clone is the C drive if you boot the clone, evein if the source is visible to the clone on the first boot after the clone has been made.
[toc] | [prev] | [next] | [standalone]
| From | AndyHancock <andymhancock@gmail.com> |
|---|---|
| Date | 2012-02-23 18:49 -0800 |
| Message-ID | <12bc6cd6-0728-4b52-934e-590f567ca7f6@ge5g2000vbb.googlegroups.com> |
| In reply to | #2666 |
On Feb 23, 4:04 am, "Rod Speed" <rod.speed....@gmail.com> wrote: > AndyHancock wrote >> I believe we were discussing why it isn't such a big disaster for >> the clone to do its virgin boot with the source HDD still visible. >> Basically, the clone can be remade. > > Yes. > >> However, I was wondering if the process of booting the clone could >> lead to disk-writes to the source HDD. > > No they dont. > >> After all, the clone gets a drive letter other than C-drive, > > No it doesnt. The clone gets the drive letter C OK, I think this is where I get lost. According to http://www.goodells.net/multiboot/partsigs.shtml : "do not let new-XP see the old-XP partition the first time it boots. If new-XP sees old-XP, it won't reuse the original drive letter when it assigns a drive letter to itself." I realize that this is XP whereas I'm using Windows 7, and I recall that you said that the article was not entirely accurate. Is this one of the facts that are wrong? >> but its registry still contains paths to the C-drive file system > > Yes. > >> (which is the source HDD). > > Nope. The clone becomes the C drive and so the registry entrys still > point to the clone. > >> Does the boot process use the paths stored in its registry in any >> way that could result in a write to a file in one of those paths? > > Yes, but since the clone gets the letter C, that doesnt affect the > source. > >> This is not the same as whether the boot process writes to the >> registry in the source HDD, > > That only happens if you boot the source. > >> which is what I assumed you were talking about. For that matter, >> what if someone hypothetically booted off the clone and failed to >> notice it (not that I or anyone else would do that). > > Then if the source is visible on the first boot of the clone, you > end up with a boot that is normal but you will find that if you then > remove the source, and boot again, you cant boot anymore because the > early boot phase uses files on the source which isnt there anymore, > so the boot fails. > >> Would the routine use of windows cause writes to files whose paths >> are contained in the registry? > > Yes. > >> Some of those paths are paths to the C- drive. > > Yes. But the clone is the C drive if you boot the clone, evein if > the source is visible to the clone on the first boot after the clone > has been made.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2012-02-24 15:58 +1100 |
| Message-ID | <9qojn8Fu4qU1@mid.individual.net> |
| In reply to | #2667 |
AndyHancock wrote > Rod Speed <rod.speed....@gmail.com> wrote >> AndyHancock wrote >>> I believe we were discussing why it isn't such a big >>> disaster for the clone to do its virgin boot with the source >>> HDD still visible. Basically, the clone can be remade. >> Yes. >>> However, I was wondering if the process of booting >>> the clone could lead to disk-writes to the source HDD. >> No they dont. >>> After all, the clone gets a drive letter other than C-drive, >> No it doesnt. The clone gets the drive letter C > OK, I think this is where I get lost. According to > http://www.goodells.net/multiboot/partsigs.shtml : > "do not let new-XP see the old-XP partition the first time > it boots. If new-XP sees old-XP, it won't reuse the original > drive letter when it assigns a drive letter to itself." > I realize that this is XP whereas I'm using Windows 7, > and I recall that you said that the article was not entirely > accurate. Is this one of the facts that are wrong? Yep, and its trivial to test whether its wrong or not. >>> but its registry still contains paths to the C-drive file system >> Yes. >>> (which is the source HDD). >> Nope. The clone becomes the C drive and so the registry entrys still point to the clone. >>> Does the boot process use the paths stored in its registry in any >>> way that could result in a write to a file in one of those paths? >> Yes, but since the clone gets the letter C, that doesnt affect the source. >>> This is not the same as whether the boot process writes to the >>> registry in the source HDD, >> That only happens if you boot the source. >>> which is what I assumed you were talking about. For that matter, >>> what if someone hypothetically booted off the clone and failed to >>> notice it (not that I or anyone else would do that). >> Then if the source is visible on the first boot of the clone, you >> end up with a boot that is normal but you will find that if you then >> remove the source, and boot again, you cant boot anymore because the >> early boot phase uses files on the source which isnt there anymore, >> so the boot fails. >>> Would the routine use of windows cause writes to files whose paths >>> are contained in the registry? >> Yes. >>> Some of those paths are paths to the C- drive. >> Yes. But the clone is the C drive if you boot the clone, evein if >> the source is visible to the clone on the first boot after the clone >> has been made.
[toc] | [prev] | [next] | [standalone]
| From | AndyHancock <andymhancock@gmail.com> |
|---|---|
| Date | 2012-02-23 21:09 -0800 |
| Message-ID | <558119c9-a983-41c5-9e0b-a7286cf02ca0@cj6g2000vbb.googlegroups.com> |
| In reply to | #2668 |
On Feb 23, 11:58 pm, "Rod Speed" <rod.speed....@gmail.com> wrote: > AndyHancock wrote > > Rod Speed <rod.speed....@gmail.com> wrote > >> AndyHancock wrote > >>> I believe we were discussing why it isn't such a big > >>> disaster for the clone to do its virgin boot with the source > >>> HDD still visible. Basically, the clone can be remade. > >> Yes. > >>> However, I was wondering if the process of booting > >>> the clone could lead to disk-writes to the source HDD. > >> No they dont. > >>> After all, the clone gets a drive letter other than C-drive, > >> No it doesnt. The clone gets the drive letter C > > OK, I think this is where I get lost. According to > >http://www.goodells.net/multiboot/partsigs.shtml: > > "do not let new-XP see the old-XP partition the first time > > it boots. If new-XP sees old-XP, it won't reuse the original > > drive letter when it assigns a drive letter to itself." > > I realize that this is XP whereas I'm using Windows 7, > > and I recall that you said that the article was not entirely > > accurate. Is this one of the facts that are wrong? > > Yep, and its trivial to test whether its wrong or not. I know you said that it's not disastorous, but I'd rather take your word on that than to test it (at least not deliberately). Hope you understand.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2012-02-24 17:30 +1100 |
| Message-ID | <9qop4aF24uU1@mid.individual.net> |
| In reply to | #2669 |
AndyHancock wrote > Rod Speed <rod.speed....@gmail.com> wrote >> AndyHancock wrote >>> Rod Speed <rod.speed....@gmail.com> wrote >>>> AndyHancock wrote >>>>> I believe we were discussing why it isn't such a big >>>>> disaster for the clone to do its virgin boot with the source >>>>> HDD still visible. Basically, the clone can be remade. >>>> Yes. >>>>> However, I was wondering if the process of booting >>>>> the clone could lead to disk-writes to the source HDD. >>>> No they dont. >>>>> After all, the clone gets a drive letter other than C-drive, >>>> No it doesnt. The clone gets the drive letter C >>> OK, I think this is where I get lost. According to >>> http://www.goodells.net/multiboot/partsigs.shtml: >>> "do not let new-XP see the old-XP partition the first time >>> it boots. If new-XP sees old-XP, it won't reuse the original >>> drive letter when it assigns a drive letter to itself." >>> I realize that this is XP whereas I'm using Windows 7, >>> and I recall that you said that the article was not entirely >>> accurate. Is this one of the facts that are wrong? >> Yep, and its trivial to test whether its wrong or not. > I know you said that it's not disastorous, but I'd rather take > your word on that than to test it (at least not deliberately). Its completely trivial to backup the source completely so that you can always just restore that if it does turn out to get modified. > Hope you understand.
[toc] | [prev] | [next] | [standalone]
| From | AndyHancock <andymhancock@gmail.com> |
|---|---|
| Date | 2012-02-24 20:39 -0800 |
| Message-ID | <44607cde-da02-43c0-a53d-fb1b2af14c50@v2g2000vbx.googlegroups.com> |
| In reply to | #2670 |
On Feb 24, 1:30 am, "Rod Speed" <rod.speed....@gmail.com> wrote: > AndyHancock wrote > > Rod Speed <rod.speed....@gmail.com> wrote > >> AndyHancock wrote > >>> Rod Speed <rod.speed....@gmail.com> wrote > >>>> AndyHancock wrote > >>>>> I believe we were discussing why it isn't such a big > >>>>> disaster for the clone to do its virgin boot with the source > >>>>> HDD still visible. Basically, the clone can be remade. > >>>> Yes. > >>>>> However, I was wondering if the process of booting > >>>>> the clone could lead to disk-writes to the source HDD. > >>>> No they dont. > >>>>> After all, the clone gets a drive letter other than C-drive, > >>>> No it doesnt. The clone gets the drive letter C > >>> OK, I think this is where I get lost. According to > >>>http://www.goodells.net/multiboot/partsigs.shtml: > >>> "do not let new-XP see the old-XP partition the first time > >>> it boots. If new-XP sees old-XP, it won't reuse the original > >>> drive letter when it assigns a drive letter to itself." > >>> I realize that this is XP whereas I'm using Windows 7, > >>> and I recall that you said that the article was not entirely > >>> accurate. Is this one of the facts that are wrong? > >> Yep, and its trivial to test whether its wrong or not. > > I know you said that it's not disastorous, but I'd rather take > > your word on that than to test it (at least not deliberately). > > Its completely trivial to backup the source completely so that > you can always just restore that if it does turn out to get modified. True. I just don't want to get another HDD to do that though. I'm living with minimal stuff.
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | comp.sys.ibm.pc.hardware.storage
csiph-web