11 Dec
2015
11 Dec
'15
10:27 p.m.
All,
In my exploration of v6, I followed the advice in "Setting up Unix -
Seventh Edition" and copied v6tar from v7 to v6. Life is good. However,
tar is using mt1 and it is hard coded into the source, tar.c:
char magtape[] = "/dev/mt1";
As the subject line suggested, I have two questions for those of you who
might know:
1. Why is it hard coded?
2. Why is it the second device and not the first?
Interestingly, it took me a little while to figure out it was doing this
because I didn't actually move files between v6 and v7 until today.
Before this my tests had been limited to separate tests on v6 and v7
along the lines of:
cd /wherever
tar c .
followed by
tar t
list of files
cd /elsewhere
tar x
files extracted and matching
What it was doing was writing to the non-existant /dev/mt1, which it
then created, tarring up stuff, and exiting. Then when I listed the
contents of the tarfile, or extracted the contents, it was successful.
But, when I went to move the tape between v6 and v7, the tape (mt0) was
blank, of course. It was at this point that I followed Noel's advice
and "Used the source", and figured out that it was hard-coded as you see
above.
Thanks,
Will
11 Dec
11 Dec
10:31 p.m.
First, the device # should be usable from the command line, i.e. tar cv0
foo
As for mt, it was written for the tape device and in those days most of us
had at least one 9-track device. I have no memory of why Ken used mt1
not mt0. Doug may know.
On Fri, Dec 11, 2015 at 5:27 PM, Will Senn <will.senn(a)gmail.com> wrote:
All,
In my exploration of v6, I followed the advice in "Setting up Unix -
Seventh Edition" and copied v6tar from v7 to v6. Life is good. However, tar
is using mt1 and it is hard coded into the source, tar.c:
char magtape[] = "/dev/mt1";
As the subject line suggested, I have two questions for those of you who
might know:
1. Why is it hard coded?
2. Why is it the second device and not the first?
Interestingly, it took me a little while to figure out it was doing this
because I didn't actually move files between v6 and v7 until today. Before
this my tests had been limited to separate tests on v6 and v7 along the
lines of:
cd /wherever
tar c .
followed by
tar t
list of files
cd /elsewhere
tar x
files extracted and matching
What it was doing was writing to the non-existant /dev/mt1, which it then
created, tarring up stuff, and exiting. Then when I listed the contents of
the tarfile, or extracted the contents, it was successful. But, when I went
to move the tape between v6 and v7, the tape (mt0) was blank, of course. It
was at this point that I followed Noel's advice and "Used the source",
and
figured out that it was hard-coded as you see above.
Thanks,
Will
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
10:52 p.m.
On 12/11/15 4:31 PM, Clem Cole wrote:
First, the device # should be usable from the command
line, i.e. tar
cv0 foo
As for mt, it was written for the tape device and in those days most
of us had at least one 9-track device. I have no memory of why Ken
used mt1 not mt0. Doug may know.
Clem,
Thanks, that'll teach me to read the man pages more carefully even when
the command is familiar in its modern form. Your tip about the device
number caused me to check. Sure enough, it's in the documentation :). I
am so impressed with the durability of the original documentation. These
were written some 40+ years ago, and they're still amazingly useable by
folks like me who have only worked with OSes created since the 1990's
(of course, not entirely without help).
man tar
...
0,...,7 This modifier selects the drive on which the tape
is mounted. The default is 1.
...
-will
11:13 p.m.
Will Senn scripsit:
Thanks, that'll teach me to read the man pages
more carefully even
when the command is familiar in its modern form.
Note that if -f is not given, modern tars still default to the tape
drive, /dev/st0 on Linux or /dev/sa0 on *BSD.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
Barry thirteen gules and argent on a canton azure fifty mullets of five
points of the second, six, five, six, five, six, five, six, five, and six.
--blazoning the U.S. flag
12 Dec
12 Dec
12:26 a.m.
On 2015-12-11, John Cowan <cowan(a)mercury.ccil.org> wrote:
Will Senn scripsit:
That depends on the tar. A lot these days default to stdin (or
stdout as appropriate to the operation). Many don't even support
the "drive number" option. OSX knows nothing of the options, and
Ubuntu's GNU tar says:
tar: Options '-[0-7][lmh]' not supported by *this* tar
GNU tar has the capability, but it's apparently not a very
well-used feature, since the ./configure script it ships with
has a bug in a sed command meant to convert e.g. "/dev/st0" to
"/dev/st" [prefix for 0-7 to be appended to].
Star switched in 1982, according to the author. And in any case
even when POSIX did define tar, it only said the default was
"system-dependent".
The only one I could find that keeps this alive is bsdtar
(libarchive) which apparently will even use something called
\\.\tape0 if compiled for Windows. But it doesn't actually
support the 0-7 options.
Well, that and OpenSolaris tar. Which apparently gets devices
_and_ blocking factors corresponding to arguments 0-7 from
/etc/default/tar:
Thanks, that'll teach me to read the man
pages more carefully even
when the command is familiar in its modern form.
Note that if -f is not given, modern tars still default to the tape
drive, /dev/st0 on Linux or /dev/sa0 on *BSD. archive0=/dev/rmt/0 20 0
archive1=/dev/rmt/0n 20 0
archive2=/dev/rmt/1 20 0
archive3=/dev/rmt/1n 20 0
archive4=/dev/rmt/0 126 0
archive5=/dev/rmt/0n 126 0
archive6=/dev/rmt/1 126 0
archive7=/dev/rmt/1n 126 0
(The third argument is a size parameter; you're supposed to use
it if you define one of the devices to be a floppy drive.)
3068
days inactive
3069
days old
4 comments
4 participants
participants (4)
-
Clem Cole -
John Cowan -
Random832 -
Will Senn