Date: Sat, 13 Oct 2001 18:35:05 -0400
From: Richard Feltenberger <[EMAIL PROTECTED]>
Subject: Re: copying data problem?
Karen,
The source computer can only use the drives which exist on the target.
I would suggest that partitioning would be dangerous, and I would be
afraid to try it.
Might this solve your problem:
Using the source computer, and apparently the e drive is the target's
C drive. If this is true, go to the E drive, and make a directory
maybe called NEW. Now change to that directory, and copy all of your
directories from the source as sub-directories on e:\new\.
This will keep your transferred files completely separate from the
files which exist on the target computer.
I hope this is helpful.
Richard
On 2001-10-13 [EMAIL PROTECTED] said:
>CC: <[EMAIL PROTECTED]>
>eeeeeeek!
>richard, if you had told me this from the start, i would have known
>without needing the reader which was the drive leter for the target
>drive. i had no way to confirm this from the source save using msd,
>which wasnot giving me correct data.
>having said, this, i am going to try to ask the questionmore
>carefully this time, as i still must do something with the data on
>the source computer. *is there a way to send the data from this
>source computer to a target computer, with this data going
>somewhere other than the c drive of that target computer? for
>example, need i partition part of the c drive on the target
>computer first, run the programs as outlined, and then use
>interlink to learn how the drives are setup?* the only reason i
>needed a reader in the first place was to tell me which drive was
>the right one on the target computer. knowing about interlink
>would have saved alot of time. karen
><who is very sorry she sounds unkind!>
>On 2001-10-13 [EMAIL PROTECTED] said:
>>Date: Fri, 12 Oct 2001 18:50:27 -0400
>>May I add one more item to your excellent check list. If you type
>>interlnk
>>on your source computer, it will tell you whether you have a
>>connection, and which drives belong to the slave computer.
>>On 2001-10-12 [EMAIL PROTECTED] said:
>>>Date: Fri, 12 Oct 2001 10:19:22 -0400 (EDT)
>>>Hi, Karen,
>>>Here's what you need to do on each computer, to know what you get
>>>with the interlnk and intersvr pair. You've seen all of this
>>>before, but it will provide you a checklist, alohng with tips on
>>>what to look for to know if you actually got intersvr running.
>>>First, add up the number of drives on both computers, the source,
>>>and the target. For example, if the source has floppies A: and
>>>B:, one hard drive and one CD-ROM drive, that gets you through
>>>Drive D:. If you use a RAM drive, that one would also get a drive
>>>letter. The Target has at least two floppies, making for Drives
>>>E: and F:, and at least one hard drive, (in this example) now G:
>>>for your two-system network.
>>>On the source, (InterLnk) machine, put a line in your config.sys
>>>file that says:
>>>lastdrive=X
>>>where "X" is not the letter X, but the letter of the highest drive
>>>letter. Add one just to be safe. If each computer has four
>>>drives, that would give you 8 total, to the letter "H". Add one
>>>just to be safe and say:
>>>lastdrive=I
>>>On the device line that loads Interlnk.exe in config.sys on the
>>>source machine, the one with the screen reader running and with
>>>the synth, the line can either be:
>>>device=c:\dos\interlnk.exe
>>>or:
>>>device=C:\dos\interlnk.exe /auto
>>>My experience shows that, if you are using a parallel connection,
>>>it doesn't seem to matter if you specify the /auto switch, since
>>>it seems to be the default mode of operation and the program
>>>polls the ports until it finds the type of connection it is
>>>looking for. NOw, let's go to the target, (intersvr) machine.
>>>This is simple. If the machine's autoexec.bat has c:\dos as part
>>>of the path statement line, you only need to type:
>>>intersvr
>>>and press the Enter key. I find that, for some reason, I have to
>>>press the <enter> key a second time for some reason. Since you
>>>don't have a synth and a screen reader on that machine, you won't
>>>hear the intersvr's message that says, "This computer ... Other
>>>computer". with the running counter of transfer activity in bytes
>>>going between the two machines.
>>>If you know you have four drives on the source machine and three
>>>on the target, you know that your highest possible drive letter
>>>with a valid drive specification is going to be G:. At the C:\>
>>>DOS prompt on the source machine, type something like:
>>>vol G:
>>>and press the <enter> key. If InterSvr is running, the source
>>>machine will see G: and return the message you would expect:
>>>Volume in Drive G: is ...
>>>If you get Drive not ready reading G:
>>>or:
>>>Invalid Drive specification
>>>you can suspect that, either your cable connection is not secure,
>>>or maybe you typed something on the intersvr command line that it
>>>thought caused a "bad command or filename" or it just didn't load.
>>>As for a boot order, turn on and boot up the source machine first,
>>>before invoking the intersvr command on the target machine. Some
>>>people have told me they needed to then reboot the source machine
>>>after invoking the intersvr command on the target machine, but
>>>I've never run into that, even using the interlnk/intersvr
>>>program pair on machines running different versions of DOS from
>>>different DOS distributors, as in MS-DOS 6.22 on one machine and
>>>PC-DOS 7.00 on the other.
>>>To get out of Intersvr mode on the target computer, press the
>>>Alt-F4 key combination to exit Intersvr, and maybe the <Enter> key
>>>to confirm. You can verify on the source machine by asking DOS
>>>for the volume label or a dir of G: and it will give you that
>>>"invalid drive specification" or that "Not ready reading Drive
>>>G:" message. If you have a device with a passthrough port
>>>connected to a parallel port on one machine, such as a parallel
>>>ZipDrive, or maybe your hardware key dongle of some sort, that
>>>device should be on the source machine. I have never done it
>>>with such devices on both machines, but my "laplink" cable does
>>>connect on the source machine to the passthrough port on the
>>>ZipDrive which is connected to the parallel port of the source
>>>machine, and the other end is connected to the parallel port on
>>>the target machine. The only problem with that is that I can not
>>>dirrectly transfer data between Drive G: on the target machine
>>>and Drive D:, which is the ZipDrive. It has to go to C:\> first.
>>>It does not interfere with speedy transfers from G: on the target
>>>computer to C: on the source machine for some reason. That has
>>>something to do with the configuration of how stuff moves through
>>>the ZipDrive's parallel port passthrough, which is designed with
>>>the idea that you might only connect your printer there, and the
>>>printer does not need to send a whole lot of message traffic back
>>>to the computer except handshaking and status stuff. If you have
>>>any questions or problems, and if you think I might be able to
>>>help, and you want a walkthrough on the phone, just give me a
>>>quick call late some evening and I can call you back and we can
>>>try to figure out what might be going on. My number is,
>>>404-814-0768 and it works 24-7, taking messages if I'm not in, or
>>>if the computer is on the line. Please let us know when you get
>>>it up and running and get the stuff transferring.
>>>Brent Reynolds
>>>Random Access Internet Shell account
>>>Standard disclaimers apply.
>>>Email: [EMAIL PROTECTED]
>>>*******************************************************
>>******************************
********************************************************
To unsubscribe from this list,
send a message to [EMAIL PROTECTED] with the single word
Unsubscribe
as the subject.
You MUST use the same address with which you subscribed!
********************************************************
