SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
USA

SCOUG-HELP Mailing List Archives

Return to [ 18 | February | 2004 ]

<< Previous Message << >> Next Message >>


Date: Wed, 18 Feb 2004 13:51:14 PST8
From: waynec@linkline.com
Reply-To: scoug-help@scoug.com
To: scoug-help@scoug.com
Subject: SCOUG-Help: Re: HD Cloning Disaster, DFSEE not to the rescue

Content Type: text/plain

=====================================================
If you are responding to someone asking for help who
may not be a member of this list, be sure to use the
REPLY TO ALL feature of your email program.
=====================================================

I think what I would attempt would be to use dfsee 6 (only version I have
available to me at the moment, it's downloadable for free trial) to first
select the new drive (File > Open disk) and use the "fdisk" menu of dfsee to
create a new mbr (Mode=FDISK > New MBR code); if that's successful, then go
back and select the old drive, and then use dfsee's clone feature to clone
it to your new drive (Actions > Clone from whole disk).

Wayne

J. R. Fox writes:
>
> This seems like a good place to segue, on the heels of Sheridan's post about partition corruption. How
> much
> of a mess can you make, by the simple act of trying to clone a hard drive ? I may have just found out.
>
> Having irretrievably (?) lost the two W2K partitions on my desktop system some months ago, I wanted to
> gain some insurance for the ones that are working fine on the Shuttle portable, esp. before I put eCS and
> System Cmdr. on it and do some other possibly risky maneuvers. (Drive trays are not a practical option
> for
> this little unit, so I'm stuck with the problems of a multiboot setup.) So, I got a 2nd. identical H/D,
> and set
> about cloning everything as it exists at the moment -- some 18 partitions worth, including ones reserved
> for
> IBM Boot Mgr., and two eCS partitions. Everything was going great, up until the very end. (Beware
> whenever
> things seem to be going really well ! The edge of the cliff may be right there, just over the next rise.)
>
> Let me back this up a bit for you. This is supposed to be a simple, straightforward procedure, right ?
> The
> first tool I reached for was GHOST 2003, by most accounts a capable product, but one with a rather dumb
> design in its UI. The drive-to-drive procedure with GHOST bombed out immediately, with an error message
> that said "Call Symantec." Uh, no thanks. (I'm positiive that it did not get as far as starting to do
> anything with
> the bare drive.) I next turned to Drive Image 4, a better program I'm quite familiar with at this point.
> Right
> away at the setup phase, I could see that its Drive-to-Drive feature -- unlike its regular Imaging feature
> --
> could only see the few FAT-16 partitions. So much for that.
>
> I recalled that Ray has mentioned cloning *partitions* with Partition Magic, a number of times. O.K.,
> that's
> taking the longer, slower, labor intensive route, but it should get me to the destination. So I started
> to clone
> each partition in turn, drive to- drive, with PM-6. This program spends a lot of time verifying the
> target media
> *first*, then verifying the partitioning / formatting / data copy the rest of the way -- so we're talking
> several
> hours overall. Everything proceeded smoothly, right up through partition 17. Maybe I should have had
> some
> concern that there were tiny variances in the size of the cloned partitions. Like 305.8M vs. 305.9M. Now
> I can
> tell you where I probably screwed up, on the final partition, but PM screwed up much worse on the disaster
>
> avoidance part of its design. Ray had asked me, "Isn't there a PM gotcha about the source & destination
> partition
> sizes having to be the same, or larger at the destination end ?" This was a an easily preventable
> oversight on my
> part, but the destination space was less than half a Meg. too small -- largely because of these very
> small, but
> cumulative differences ! At the end of cloning the last partition, PM barfed. Worse yet, it wiped out
> the first
> partition *along with* the MBR, in a way that may be unrecoverable. If the damn program had been properly
>
> designed, it should not even have attempted to clone the last partition, but seen a mismatch and returned
> a
> "Nope, you can't do that" sort of error.
>
> PM can no longer deal with the cloned H/D in any fashion. It takes one look at the drive and gives forth
> an
> Error #108, the meaning of which seems to be: "Sorry Pal, but you are utterly, totally *****d."
> (PowerQuest
> was bought out by Symantec, so I guess one is supposed to call the latter now, and shell out serious
> dinero for
> live support, if they even still support a version that old. Again, no thanks.)
>
> Enter DFSEE. Except for a couple relatively simple things, like Set Partition Active (much more
> accessible
> now, with the GUI version), I've never really learned how to use this program. I recognize that a lot of
> work
> has gone into making it more non-techie friendly, and into revising the documentation and Help. But I'm
> sorry: reading through that stuff still makes me feel like a dolt. I know that it has partition and whole
> drive
> cloning features, and maybe I should have tried the latter, from the get-go. Anyway, at the moment I am
> much
> more interested in its analysis and recovery features. It so happens that I have the DFSTART files from
> the
> Source drive. However, so far I can't see that this is going to be helpful. DFSEE (5.54) shows that
> Partition 1
> has been turned into Free Space, and that Partition 2 (the alternate C: partition) is now the first actual
> partition.
> Attempts to do anything to or with that free space results in a DFSEE error #252, General Command Failure.
>
> It is like that first 305M is there, but it _isn't_ there at the same time -- or it is at least
> untouchable.
>
> In theory, PRESTORE should be able to resurrect the MBR from the DFSTART files, and the first partition
> should be re-clonable. But I'm not sure how to get there from here, or if it has any prospect of
> working. It
> sure would be nice to salvage the work already done, if the results can be reliable. Or maybe I should
> just wipe
> the duplicate drive (not sure How), and try the DFS drive to drive cloning. The one thing I want to be
> damn
> sure of is that nothing adverse happens to the Source drive, in the course of attempting this.
>
> If anyone has a step-by-step for me here, it would really be appreciated.
>
>
> Jordan
>
>
>
> =====================================================
>
> To unsubscribe from this list, send an email message
> to "steward@scoug.com". In the body of the message,
> put the command "unsubscribe scoug-help".
>
> For problems, contact the list owner at
> "rollin@scoug.com".
>
> =====================================================
>
>

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================


<< Previous Message << >> Next Message >>

Return to [ 18 | February | 2004 ]



The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.