Data Transfer Ideas
You need to transfer data from machine A to machine B. Maybe you
are lucky enough to have networking on both machines, but maybe you
aren't. Maybe you have tape drives, but they are incompatible. Or
maybe they should be compatible, but they don't seem to want to
work. Maybe you don't have tape drives or a network, but you still
need to transfer that data. How?
There are a number of possibilities, depending on what you have
and what your time frame is. In general, you are usually better off
making archives on the machine you are transferring from rather
than transferring individual files one by one. You might do that
with tar, for example, using something like:
tar cvf /tmp/files.tar .
Which will create an archive of the current directory into
/tmp/files.tar which can be transferred to the new machine and
tar xvf /tmp/files.tar
Note that some versions of tar allow multiple archives, which can be used in
concert with whatever flag limits the volume size (-L Linux, ), so you can
do something like:
tar -c -L 50000 -f archive1 -f archive2 -f archive3 ... path
to split an archive into more conveniently sized chunks if needed (for
example if you will later copy them to floppy or cd's). To extract them, you can "cat" them and pipe to "tar xv"
(Windows tar binaries.)
However, there are times when it's simpler to just pick and
choose individual files. If you are transporting binary files by
any method that requires text files, the "uuencode" program is
needed. You use uuencode like this:
uuencode myprog myprog > myprog.uu
cat myprog | uuencode myprog > myprog.uu
At the other end, you unpack it by:
See "man uuencode" for more information. If you want to compress
a file, compress it before you uuencode it.
If this is a one time transfer of data (an upgrade, for
example), a commercial data conversion company might be the
simplest solution. You can find these companies in the Yellow Pages
under "Data Conversion", or on the web. Locally here in
Massachusetts I use Disc
Conversion houses usually work only with tape or sometimes other
media like the old Bernoulli cartridges, etc. If you don't have
tape, and don't have any other way to move the data, a data
recovery company could extract the data from your hard drive and
put it on CDROM or tape. Admittedly, this is extreme, and it's apt
to be expensive, but if there is no other way to get the job done
in the time constraints you are working with, this can be the
answer. Some national firms include:
This could be an option if you have a modem and can configure
(or already have configured) mail on the old machine. You will need
to uuencode files (see the top of this article).
Perhaps it is possible to mount the hard drive from one machine
as a file system on another. This is very easy if the hardware is
the same and you are both coming from and going to Unix.
This section is specific to SCO Unix
example, you have SCSI drives, you'd add in the old drive exactly
as you would add a new drive, except that you would NOT overwrite
the file systems already there. You will need to name the divisions
(they'll have no names when you get to divvy), and if they are old
Xenix you'll also need to run "mkdev xenix" to add support for
these old file systems.
SCO has technical articles that cover this in detail:
If it's IDE, the procedure is basically the same, but if you need
to mix SCSI and IDE you might have a problem because at this time,
the IDE MUST be the boot drive- even if your computer BIOS allows
otherwise, the SCO OS will not, at least not at the time this was
written. You can always add a SCSI drive to an IDE configuration,
but not IDE to a SCSI booted system.
A possible way out is to temporarily install SCO on a spare IDE
system, install the other drive, and finally transfer the data by
tape or network to the system you really want it on.
DOS drives can be mounted, but only (again, as of this writing)
FAT-16, not FAT-32.
See Reading SCO tapes on Linux also.
Linux and SCO Unix can support multiple tape drives. That means that you
can have several different tape drives all physically installed and
working at the same time. You can mix SCSI and non-SCSI tapes,
DAT's, QIC's, whatever (though some older QIC drives with their own
adaptor cards do have to be the default drive). This might mean
that you can take the old tape drive out of the old machine,
install it in the new machine, and just restore your data.
If that can't be done (physically inconvenient or no drivers for
the older tape drive), it may be that newer drives can read the
older tapes. For example, QIC tape drives have remained beautifully
backward compatible- the newest 2.5 gigabyte models can still read
the old DC600 60 megabyte tapes.
Sometimes you have the same physical tape and drives, but can't
read the data. This can be caused by tape blocking being set
differently on the two machines; you can change that with the "tape
-a setblk" command. For example, if you were coming from a 3.2v4.2
system, that uses a fixed 512 byte tape block, while OSR5 uses
variable tape blocking. The 3.2v4.2 can use variable, but it needs
to be told to do so:
tape -a 0 setblk
(this functionality requires UOD376c from ftp://stage.sco.com)
Unfortunately, compression is another issue entirely. Different
manufacturers can use different hardware compression algorithms, so
a DAT tape created on one manufacturer's drive may not be able to
be read on another. Another problem is drives that have drifted far
out of alignment: the drive that wrote the tape may still be able
to read it, but other drives can't. Data conversion and data
recovery firms may be your only choice if you have these
UUCP is fairly easy to set up, and can work at high speed across
a hardwired serial connection. You can get UUCP for DOS and Windows
platforms, and of course all Unix platforms have it already. The
major disadvantage is speed: the serial ports are not going to
transfer gigabytes of data in any reasonable amount of time.
Consider that under the best conditions, with no overhead taken
into account, 115k baud would move less than 3/4 megabyte per
minute. That's not great when you have hundreds of megabytes to
move, and if it's an older machine, 115k may not even be
If it's just small text files, cu's "put" and "take" commands
work quite well. You use these by cu'ing to the old system, and
typing (for example)
~%take /etc/group /tmp/group
which will transfer the /etc/group file on the old machine to
/tmp/group on the machine you cu'd from. If you need binary files,
you'll need to uuencode them; see the beginning of this
Linux systems have "minicom", which can also transfer files.
Most of the UUCP books are out of print, so it's hard to find
anything more than the documentation you have on your system.
Fortunately the built in SCO documentation is pretty good. If you
need UUCP for DOS or Windows, you can probably find it in Google.
If you have small amounts of simple text to transfer, you can do
it just by catting or even printing it to a serial terminal
emulation program. This is a possibility when you have no real
access to the computer that has the data on it. If you can print
the data you want to a serial port, you can capture it using a
Some terminal software (for example ICE.TEN by James
River) includes file transfer capability. If you are already using
such software, you may already have everything you need.
For larger needs, where UUCP can't be used, many systems have or
can use Kermit. I think you can even still find Kermit for Xenix!
Kermit runs on just about every OS ever made, and
it can work over serial or TCP/IP connections. This makes it an
excellent choice for data transfer.
Particularly see http://www.columbia.edu/kermit/gkermit.html#boot
Another possibility is Xt.
If you are going to or coming from a Dos or Windows system with
Zmodem, Xmodem or Ymodem, you can get Rz and Sz for Unix (See
TLS025 at http://www.sco.com/skunkware).
Another interesting solution
(assuming a Unix to Unix transfer) is to use Expect (see Book Review: Expect). This has the
advantage of requiring nothing beyond the usual Unix utilities:
(cat, compress, uuencode, etc.) on the "other" machine. You can
download Expect from http://expect.nist.gov. The file
transfer program will be found in the "example" subdirectory after
you unpack the distribution; it's called "ftp-inband". Note that
you need TCL for Expect: if you install Expect from Skunkware it
will automatically install TCL also.
Kermit can sometimes be used in ways similar to Expect; see
Here's an example of the simple serial method: I had a Xenix 2.2
machine recently (Apr 2000) that was on its last legs. A Foxpro
database had 9,000 records that the customer wanted to transfer to
Act. Neither the Xenix floppy nor its tape drive worked at all. I
wrote a small Foxplus program that put the data out to a file, and
then used Hyperterminal to log in to the Xenix system, turned on
"Capture" and typed "cat /tmp/datafile". At 19.2K, this took about
a half an hour or so to transfer approximately 4 megabytes. I
needed to do some further conversion work that would have been slow
and painful on the old Xenix system and impossible on Windows, so I
emailed the file to myself using the client's AOL account. After
cleaning up the data back at my office and converting it to a CSV
format, I emailed it back to the client.
Although not particularly fast, copying off to floppy on one
machine and reading on another is certainly simple. Set up a two or
three disk rotation so that you can be reading while copying.
Beware of the disks wearing out: at 25 cents each, you really
didn't expect them to last for a hundred uses, did you?
For transferring small files to and from Dos, the "doscp" (or
mtools from Skunkware) can be used.
Windows "tar" was mentioned above.
If you have downloaded patches, etc. to a Windows machine and
you have a network connection, of course you can just ftp the files
over. If you do not, you need to do it by floppy, and you will
immediately realize that most of the patches are disk images: they
are 1.44 MB and will not fit on a DOS floppy. There is a utility
(RAWRITE) that will solve this problem for you. Download it from
for more information.
Jaz drives, etc. can be installed on Unix systems if they are
Modern Linux systems of course accept much more - the USB stick in your pocket, for example.
Ssh's 'scp' is a very easy way to do transfers: scp -r thisdir root@somehere:
scp:If coming from Windows and the Unix box is running ssh, you might
be able to use "pscp" ( get it for Windows from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html ).
The ftp program is probably the
easiest way to transfer files between machines. You can make it
easier in several ways by learning a few basic ftp commands.
Here's an example ftp session that illustrates some of these
# ftp oldmachine
Connected to oldmachine.
220 oldmachine FTP server (Version 2.1WU(1)) ready.
331 Password required for root.
230 User root logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
200 Type set to I.
Hash mark printing on (1024 bytes/hash mark).
ftp> prompt off
ftp> mget *.txt
The "bin" makes sure that binary files will be transferred
correctly. That's the default on SCO machines, but it doesn't hurt
to be certain. The ONLY time you want "text" (the opposite of
"binary") is when you are transferring text files between different
OS's; for example Windows to Unix. If you are transferring binary
files, or transferring between the same OS, you want "binary".
The "hash" turns on hash mark (#) printing for evey 1024 bytes
transferred. This gives you a visual indication of progress and
lets you know if you are "hung" on Internet transfers.
The "prompt off" allows us to use "mget" and "mput" without
being prompted for every file the pattern matches (if you DO want
to be prompted, use "prompt on".
Ftp transfers can be automated. The Expect
program can be used to recursively descend sub-directories, etc.
Or, you can use ftp's .netrc file. The .netrc file must be in the
home directory of the user invoking ftp, and must not be readable
or writable by other users. Here's an example .netrc file:
machine oldbox login root passwd rootpass
The "macdef" keyword defines a macro. Macros are executed by
typing the name preceded by a "$"; the "init" macro is executed
automatically after login. Note that the .netrc must end with a
blank line. See "man netrc" for more information.
If you are transferring data to or from Windows machines, and
have Visionfs or Samba (see Visionfs) you can just drag and drop files over.
NFS is often available on Unixish systems.
I've also used Samba to mount SCO machines: On the Linux
/bin/mount -t smbfs -o username=foo,password=foobar //srvr_045/croot /thatoldscobox/currcheck
If this page was useful to you, please help others find it:
More Articles by Tony Lawrence
- Find me on Google+
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site:
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Publishing your articles here
Jump to Comments
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.