#Un*x <> Amigados Query
49 messages in this thread
I've dl'd the tar.lzh utility from the libraries and now find that it
expects to use an AmigaDos disk. Is there any other way to transport data
from the Un*x side of my A3k to the AmigaDos side without going through
some intermediate network connection? I don't have a network connection
for the Un*x side anyway. When they updated the machines they left most of
the networking stuff out for space reasons. (I'm a grad student at VPI with
one of the 100 MB disk machines :^)
I guess what would be best is a way to mount a SysV disk under AmigaDos,
but the Commodore Reps said that to the best of their knowledge no one has
written a SysV device handler yet. Is there a way to move stuff on the
semi-formatted tar/cpio disks, i.e., no "makesys" run on it yet? That is
what I expected the tar.lzh utility to provide.
Thanks in advance <- Nathan ->
I believe the tar utility will let you extract tar files that have been
made on UNIX *as files* and then un-tar them on your Amiga. As far as I
know there is no tar utility that expects the floppy to be in tar format.
And, without going through some "third party" (another machine) I can't
think of a good way to transfer your file over to the Amiga side. If you
have a friend with a modem, you can try transfering the file to him or her
and then download it to the Amiga side from that machine.
Just out of curiosity, what UNIX program did you use to download the
program? Does "cu" or "tip" have x-modem downloading capabilities, or does
SYSV4 include a new terminal program?
Steve
There are various unix pd programs for xmodem, ymodem, zmodem downloading.
Most of these include makefiles for both BSD unix and ATT SYSV flavors.
Mike
Yes, I know of those programs, and I've used them. I've always see it used
like: dial up to UNIX box with [insert your favorite Amiga model here],
start the x/y/zmodem program….download away. I just don't remember ever
seeing a terminal program that you start from UNIX to dial up to someplace
(say, CIS for example) and then download programs.
Steve
Chuck Forsberg's (inventor of Zmodem) Pro-YAM program is a full blown
terminal package for *NIX that has built in X,Y,Z. I have yet to see a
Quick-B for *NIX
Lee Bosch
– via Whap!
Thanks for the information. I've never heard of Pro-YAM.
Steve
There is a procomm clone called pcomm for unix boxes that does what you'd
like (most of the time 🙂 … I believe it is public domain and available
over the internet … I can probably track down more info for you if you
need it …
jake
Ah….now that you mention "pcomm", I remember seeing it a while back. I
think it floated by one of the sources newsgroups on USEnet a few months
ago. Thanks for refreshing my memory.
Steve
There is a terminal program called PCOMM available for Unix (I don't recall
what version is the latest) that does that trick. It compiled without
problems on the Unix boxes I have available. But I don't normally have much
use for that with these machines so don't use it much.
Mike
I have used 'pcomm' and had a fair amount of success with it … it does
flake out occasionally, and as I remember, it fails utterly on the most
recent release of SunOS (4.1) … I have found that the most reliable and
available serial file transfer protocol is kermit. I have had to send
files to everything from MS-DOG (:-) PCs to VMS machines and have found
kermit to be the de facto universal standard … unfortunate perhaps as it
is supposed to be a dog in terms of performance, but it does work.
jake
I've used kermit quite a bit between different machines and have generally
found it to be pretty good in terms of performance. It does help to be
using one of the newer versions which supports the larger block sizes. Then
if you have good connections you can cut down the amount of handshaking
'overhead'. Zmodem, which is very fast on clean lines, can turn into a
horrendous dog "resyncing" if the lines get noisy. You pays your money and
takes your choice.
Mike
I was operating under the AmigaDos side when I dl'd the tar utility.
As far as I can tell there is no real terminal program shipped with SysVr4
other than "cu". I did a "man" on tip and there was no entry. Reading
through the man pages on cu, I didn't see anything on xmodem.
'til later Nathan
Nathan,
It is my understanding that the tar.lzh file we have is the Unix tar,
recompiled with an Amiga compiler. Could you not get it from your Unix
machines at VPI, or else by ftp? I think that might be easier than writing
a driver!
Betty
The problem is that the campus machines that I have physical access to
aren't Amigas. I can ftp to a IBM 4081, Vax 11/785, DecStation 5000, or a
Mac II (and have accounts on all of them too :^) ) but that doesn't get it
to my machine at home.
There are a number of items I would love to get from Internet (starting
with twm so that I don't have to put up with olwm anymore) but I usually
connect to the outside world using a comm program on the Ami side and
anything I get I can't move at this point.
'til later Nathan
Nathan,
In addition to my earlier message, you might consider picking up the
UUCP package that is available for the amiga. I know that it's available
in one of the Amiga forums, but I don't remember which one.
The problem with this idea, is that although you could install it on
your own machine easily enough, it normally requires root privledges on a
'regular' unix system to configure it's UUCP to recognize your machine.
This means that you would have to find a friendly SYSOP to set up a UUCP
connection for you on his machine.
The nice thing with using UUCP, is that nearly every unix system sold
has this package. It is used extensively to transfer files, including
support of USENET News, which is a distributed BBS-like system supporting
over 400 interest groups (called newsgroups).
If I seem pedantic, I am so for two reasons: 1) I am uncertain of your
level of experience with UNIX, and 2) It has been my experience that when I
am not what most people call pedantic, I am generally misunderstood.
Perhaps it's a flaw in my communications skills. Suggestions are welcome!
Hopefully Helpful,
Edwin Wiles – elw@netx.com (I got a *domain*!) – Software Engineer
Edwin,
Ahhh, yes … the old uucp feed problem. Unfortunately these days, it
is getting hard to find a site that will even give you a mail feed (i.e. no
news, just demand feed for mail traffic in either direction). One
possibility for people who can't find a feed is the uunet organization. I
don't have addresses, etc. handy (postmaster@uunet.com might work, of
course if you don't have access, that isn't very helpful), I could
probably dig up phone numbers and snail mail addresses if someone here
really needs them. Also, in the interest of universal net interconnection,
I can give anybody a mail feed that is willing to call Colorado to get it
… for just mail, it would be fairly inexpensive (of course it depends on
how much mail you send/get). My A500 based node (crises) has a good feed,
just one hop from the center of the net universe (ncar) … I can routinely
get a message sent out in the morning and receive a reply in the afternoon.
Of course, all this is moot if you are just trying to transfer between UNIX
and AmigaDOS on the same machine … just thought I would add my confused
mumblings into the fray 🙂
jake
(…!ncar!gaia!crises!jake)
This may be a little indirect, and will probably involve someone hacking
some code, but there are programs (MSH, shareware; CrossDos, commercial)
for reading/writing MS-DOS disks in Amiga drives. There are similar
programs for Unix machines (for example, the HP Integral Personal
Computer). I haven't seen an Amiga running Unix yet, or the level of
documentation on it's disk structure, etc… [and don't know when I'll have
the $$ to do so]. I hope this provides some clues.
Did you check on the Compuserve Unix forum? By the way, the programs on the
Unix side should be in the Internet comp.sources.unix or comp.sources.msdos
archives. When I get a chance I'll dig out some references. At the moment
my copies of the indices of these are offline while I do some file/ disk
maintenance and restoration
Cheers, Mike
I'd bet someone will come up with a scheme to do this. If you wrote a
driver for the Unix side, it would need to understand all about Amiga file
structure; vice-versa, if someone wrote a driver (file handler) for the
Amiga side, it would need to understand Unix file systems. Sounds like a
difficult task for both ends. Of course, you couldn't do a simpler active
link because you can't be running AmigaDOS and Unix at the same time.
It might be possible to use a tape as the exchange medium… as just raw
blocks, 'tar' on both sides would be happy. Or, I bet you could do it with
floppies, or a partition that acted like a tape, as just raw data without
low-level file structure.
It would be possible to write a special file system for the UNIX side…one
that could transfer files to the Amiga side. Amiga UNIX has provisions for
writing special file systems. Heck, even if they didn't, you could do it
with a special device driver. Probably make a good product too.
*I'd* do it, but my plans for getting UNIX seemed to have been pushed out a
little farther recently. 🙁
Steve
Would it implement an Amiga file system at the byte level, or just some
format that programs on both sides could read? That is, if I copy a file to
that file system on the Unix side, must I use a special tool, or will 'cp'
work? On the Amiga side, would it appear as a partition of Fast File
System, or as a magic partition that you can only access with a special
program? Heck, if you're hot to develop Unix <-> Amiga programs, I know
this company in the interchange business… 🙂
What happens on the Un*x side is as follows:
1) fdfmt > /dev/rdsk/fd0f 2) mkfs -F s5 /dev/dsk/fd0 1760 3) mount
/dev/sony
If you only perform the fdfmt, you can then tar|cpio to/from the floppy.
If you perform the mkfs, then a SysV file system is created on the floppy.
The floppy then contains superblocks, inodes and the lost+found directory
just like the hard disk. If you then mount it, you can cd to it, copy to
and from just like any other file system.
No one here really has a handle on transferring files between the two sides
so what I was hoping to find here was that someone had done something like
"msh" but for SysV.
What I find interesting is that when I place either a fdfmt'd or a mkfs'd
floppy in the drive under AmigaDos, AmigaDos realizes that it is not a
blank disk and registers the fdfmt'd floppy as "df0:." and the mkfs'd
floppy as "df0:NDOS" which would seem to indicate that there is a magic
number already written somewhere on the disk.
I'll poke around some more and keep y'all posted.
'til later Nathan
Nathan,
Please do keep us posted! Geez! From what your message says, it seems
that an important part of Unix for Amiga has been left out! To wit, a way
to transfer files from AmigaDos to Unix. Eek!
Edwin Wiles – elw@netx.com (I got a *domain*!) – Software Engineer
John,
I'm pretty sure that the release version of UNIX will have the
proper drivers for reading/writting and AmigaDOS file. I was playing with
my dealer's UX a few weeks ago…and my memory says that the manual talks
about it…but it's not implemented yet.
Don
If I were to do it, I'd make it look just like a regular Amiga file system.
Why make up yet other format? Besides, if it were a special format, it
would be better to do it like tar or cpio. From what Nathan said, it looks
like it can write to the floppy in those formats from the UNIX side. All
that would be needed is a program Amiga side that can open the floppy and
read it like tar or cpio.
Steve
Nathan,
It's fairly simple to use the low level driver (trackdisk.device)
to read/write disks on the Amiga side. Thus, if you've got the source to
tar (don't know if it was in the download or not) you could modify it
fairly easily to read from a raw disk device.
Don
The tar I dl'd contained only the executable and an explanation of its use
and the options not to use in "man" format, so its a no-go on trying to
hack it.
'til later Nathan
Nathan,
I've read a number of other replies to your question. Only one seems to
have come close to the idea you need.
{Qualifications: I work with UNIX every day, as a "support" provider
for my company. This means people come to me with their problems and I
(try to!) provide answers.}
The standard unix tar utility allows you to specify the file and/or
device that contains the tar archive. The option in question is the "f"
option.
Thus, if you can get the archive onto your system *as*a*normal*file*,
then the "tar" command should be able to unpack it.
tar tvf tarfile
.. will provide a listing of all the files contained in the archive.
tar xvf tarfile
.. will extract all the files in the archive into that directory, creating
whatever subdirectories are needed.
So, you see you don't have to have the archive created directly on a disk.
You should be able to list/extract/create tar archives on any medium, as
normal files.
Caveat: I've had no occasion to actually use the Amiga version of the tar
command. It may be in porting it that the person doing so had to make a
choice between supporting devices and supporting both devices and files.
I do hope that is NOT the case…
Good Luck!
Edwin Wiles – elw@netx.com (I got a *domain*!) – Software Engineer
Edwin,
I would hope that the distinction between devices and files is not an
issue in any version of UNIX (esp. the Amiga version, because when I can
get it for my 3000, i can finally ditch the intel slime machine that lurks
here in my office). The whole idea of devices in UNIX is that they can be
treated as files (in almost all cases) … devices are just special files
'/dev/xxx' that can be opened, read, written, and closed. The only real
differences should lie in any ioctl() calls that exist for a specific
device … as always, I could be wrong, but I thought that this was one of
the features of UNIX and (at least) many of the UNIX clones and UNIX ports
that exist treat things this way.
just my $0.02 🙂
jake
Quite correct! But since I have yet to see the Amiga Unix
implementation, I could not speak with certainty. I've seen a number of
"unix lookalikes" which had major flaws in them. Gives the OS a bad name!
<grin>
I'm waiting to purchase a 3000 until I can see what Unix is going to
look like on the Amiga. Can't wait to get my paws on it and try some
simple minded program which deliberately trashes a pointer, and then tries
to use it. If the machine guru's, then it really ain't Unix, and I
probably won't get it.
Till then, I'm crossing my fingers and hoping that it's a good
implementation! Please!
Well, get your coins ready!
Amiga UNIX does not guru, it does just like every real UNIX system does!
-mark=
Mark,
Thanks! I'm glad to hear that!
Edwin Wiles – elw@netx.com (I got a *domain*!) – Software Engineer
Edwin,
Oh…it's real UNIX. Straight from AT&T. In fact, all of the
standard scripts have the AT&T copyright in them…as does the boot
information.
Don
Speaking of UNIX….did it seem to you like it took a looooong time to boot
on the Amiga? Either the dealer or Commodore set the disk up with a HUGE
root partition, and when it went through it's fsck it seemed to take a long
time. I would have expected a couple of seperate partitions….that way it
would have been able to take advantage of a parallel fsck. (Or, if
parallel fsck isn't "standard", a rc2.d script to do a parallel fsck).
Steve
Isn't it considered normal that Unix machines are never downed unless
necessary? I've never seen a fast-booting Unix machine.
— Ethan
That's the way we keep our machines, but the machine I saw at a local store
had just been turned off without going through a shutdown procedure. (!)
UNIX generally boots pretty quickly (but, boot times are all
relative…<grin!>….it really depends on the number of scripts i:OY}ns
when it boots, and whether or not it has to run FSCK before mounting
partitions.
Steve
Steve, I guess it is time to ask the stupid question: what is FSCK?
File System Control Kernal or some such?
— Ethan
Ethan,
FileSystemChecK
It checks and repairs damaged UNIX filesystems.
It has it's limits…but if you exceed them, you more than likely
need to just start from scratch again because the filesystem is probably
hopelessly trashed.
There's also fsdb FileSystemDeBug which you can use to directly
edit a filesystem. It's complicated, and you need to know alot about how
the filesystems work…but it has saved my butt. I was able to recover an
otherwise completely lost filesystem (500 Megs large!) using fsdb to fix it
well enough to let fsck do its thing.
Don
fsdb is indeed hairy. We had to use it recently to look at a file system
that was really trashed (and unfortunately completely unrecoverable by
using FSDB). The version we have it pretty good, but it doesn't have an
option to print out info in HEX. Geeesh! I'm going to add that option
later this week.
Steve
It's File System ChecK. It's kinda like UNIX's version of DiskSalv (except
it can't recover erased files). If the file system goes bad because of a
crash, FSCK will look everything over and fix things it thinks are wrong.
Steve
Steve,
no…as a mater of fact…it seemed to boot rather fast. I don't
recall it doing an fsck on bootup. Our AT&T machines also don't run fsck
unless the filesystem valid flag isn't set.
You can't do multiple fsck's in the background since root has to be
valid, and mounted for the machine to boot…and /usr must also be mounted
and valid to enter run level 2. Thus, you must first validate root, reboot
if it required modification, and mount it…then check and mount /usr
(presuming you're going to fsck all filesystems).
I would guess the others (if any) could be checked and mounted from
that point on in the background…but at least root and /usr must be done
separately.
Oh…I forgot…there is a file on one of our machines…I forget
its name (something like /etc/checklist ) that on boot up is read, and if
any filesystems are in it…they will be checked whether the valid flag is
set or not.
Don
That's the way our machines work too. I put a parallel fsck implementation
together at work, so I'm familiar with the inability to do root and /usr in
the background. That's why we like to keep our /root and /usr as small
(but still standard…no extra add-on stuff) as small as possible. One of
the main development systems at work has several gigabytes of data on it,
so we like to get the parallel fsck's as soon as we can. 🙂
That file you're talking about is either /etc/checklist or /etc/fstab. I
can't remember either.
Steve
Steve,
I've got /usr/add-on as a mount point, so add-on is a separate
partition, makes it nice on boot…small /usr but large /usr/add-on later
on.
I checked that file today…it's /etc/checklist
/etc/fstab is where the rc scripts such as mountall look for
filesystems to mount.
Again…at least that is the way it is on our machines.
Don
Steve,
Since my place of work is going to be getting one 700 MB HD and one
1.2 GigB HD, I am very interested in this "parallel" fsck idea.
Could you send me additional info in some fashion please?
Thanks!
Edwin Wiles – elw@netx.com (I got a *domain*!) – Software Engineer
Are you running BSD, or SYSV? If you're running BSD, you've already got
it. It's the "-p" option. (You have to set up a few more thing than
that….you'll have to check the man pages). In SYSV (at least the
versions before V.4…I'm not sure about V.$), it doesn't exist. I added
that to our (the company I work for) implementation of fsck. If you do
have SYSV, check for a program called dfsck (I think that's what it's
called). The dfsck command let's you run two fsck's in parallel. The
implementation I put together doesn't have that restriction. I think we
run four or five at a time.
There are a couple things to watch out for: 1) Don't run so many in
parallel that you start swapping. The whole point of this is to get
through the fsck phase as fast as possible, and if you start swapping it
defeats the purpose. 2) Only run 1 fsck per disk at one time. If you try
and run fsck on two partitions that are on the same disk, you'll end up
taking extra time because of extra disk head movement. Since you have two
disks, you'd be restricted to two fsck's at a time (Assuming you've got
enough memory).
There's a bit more involved (handling REALLY large partions that use
scratch files instead of a lot of memory, how to optimally arrange the
order of disk checking, collating the output from multiple processes), but
that's the basic drift. If you've got source for fsck (and you're daring)
you can do what I did and add it to the fsck program itself, but I'd say
that armed with a program that can check the dirty bit on a partition and a
well written shell script, you would be able to roll your own parallel
fsck.
Steve
Steve,
Well…actually…in SVR3, at least AT&T's version…it does work.
The script /etc/mountall reads /etc/fstab for what filesystems are
automounted when going into run level 2. The script checks the filesystem
and based on the output either runs fsck on it and mounts it…or it simply
mounts it.
The way the script comes from AT&T, it uses the same named file in
/tmp (/tmp/tmp to be exact) for it's scratch file. Thus you couldn't
simply run it in the background since multiple fsck's would all try to use
the same tmp file.
But it's easy enought to pass off the parameters to a 2nd script
and run that 2nd script in the background multiple times.
(for multiple filesystems of course)
Don
Steve,
Thanks for the Info! We're runing Xenix, which is a pretty nice blend
between BSD and stock AT&T SysV. It's rather like they took the best of
both worlds, and integrated it into one environment.
I'll check our manpages for the option you mentioned.
Thanks!
Edwin Wiles – elw@netx.com (I got a *domain*!) – Software Engineer
Steve,
Oh…also forgot…the last message presumed the machine was
shutdown to firmware or power off mode prior to power off (runlevel 5 or
0). If the power was pulled, or the machine panic'ed and shutdown…all
filesystems are checked before mounting since they won't have the valid
flag set.
Don
Don,
Thanks for the info!
Edwin Wiles – elw@netx.com (I got a *domain*!) – Software Engineer