I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
I'm this close to figuring out how to get netbsd to work on fs-uae with
no prior amiga experience. Searching around the English Amiga Users's
board for clues, I found a guide on downloading and installing Amix.
Complete with amix download links. Haven't tried it myself -I'm still
working on my bsd tangent. But for anyone interested:
> From: Josh Good
> Would the command "cd /tmp ; rm -rf .*" be able to kill a V6 ... system?
Looking at the vanilla 'rm' source for V6, it cannot/does not delete
directories; one has to use the special 'rmdir' command for that. But,
somewhat to my surprise, it does support both the '-r' and '-f' flags, which I
thought were later. (Although not as 'stacked' flags, so you'd have to say
'rm -r -f'.)
So, assuming one did that, _and_ (important caveat!) _performed that command
as root_, it probably would empty out the entire directory tree. (I checked,
and "cd /tmp ; echo .*" evaluates to ". .." on V6.
The JHU version of the V6 kernel and the mount program were modified (or
should I say buggered) so that unprivileged users could mount user packs.
There were certain restrictions added as well: no setuid on mounted
The problem came up that people would mount them using relative paths and
the mtab wouldn't really show who was using the disk as a result. I
suggested we just further bugger it by making the program chdir to '/dev'
first. That way you wouldn't have to put /dev/ on the drive device and
you'd have to give an absolute path for the mount point (or at least one
relative to /dev). I pointed out to my coworker that there was nothing in
/dev/ to mount on. He started trying it. Well the kernel issued errors
for trying to use a special file as a mount point. He then tried "."
Due to a combination of bugs that worked!
The only problem, is how do you unmount it? The /dev nodes had been
replaced by the root of directory of my user pack. Oh well, go halt and
There were supposed to be protections against this. Mind you I did not
have root access at this point (just a lowly student operator), so we
decided to see where else we could mount. Sure enough cd /etc/ and mount
on "." there. We made up our own password file. It had one account with
uid 0 and the name "Game Player" in the gcos field. About this one of the
system managers calls and tells us to halt the machine as it'd had been
hacked. I told him we were responsible and we'd undo what we did.
I think by this time Mike Muuss came out and gave me the "mount" source and
told me to fix it.
I'm not sure what fd 3 is intended to be, but its the telnet socket in p9p.
By the 10/e days, file descriptor 3 was /dev/tty. There was
no more magic driver for /dev/tty; the special file still
existed, but it was a link to /dev/fd/3.
Similarly /dev/stdin stdout stderr were links to /dev/fd/0 1 2.
(I mean real links, not mere symbolic ones.)
I have a vague recollection that early on /dev/tty was fd/127
instead, but that changed somewhere in the middle 8/e era.
None of which says what Plan 9 did with that file descriptor,
though I suppose it could possibly have copied the /dev/tty
And none of that excuses the hard-coded magic number file
descriptor, but hackers will be hackers.
Here are my notes to run 8th Edition Research Unix on SIMH.
These notes are quite raw and unpolished, but should be
sufficient to get Unix running on SIMH.
Fell free to use, improve and share.
David du Colombier
Many years ago I was at Burroughs and they wanted to do Unix (4.1c) on a new machine. Fine. We all started on the project porting from a Vax. So far so good. Then a new PM came in and said that intel was the future and we needed to use their machines for the host of the port. And an intel rep brought in their little x86 box running some version of Unix (Xenix?, I didn’t go anywhere near the thing). My boss, who was running the Unix port project did the following:
Every Friday evening he would log into the intel box as root and run “/bin/rm -rf /“ from the console. Then turn off the console and walk away.
Monday morning found the box dead and the intel rep would be called to come and ‘fix’ his box.
This went on for about 4 weeks, and finally my boss asked the intel rep what was wrong with his machine.
The rep replied that this was ‘normal’ for the hardware/software and we would just have to “get used to it”.
The PM removed the intel box a couple of days later.
> On Apr 25, 2017, at 7:19 AM, tuhs-request(a)minnie.tuhs.org wrote:
> From: Larry McVoy <lm(a)mcvoy.com>
> To: Clem Cole <clemc(a)ccc.com>
> Cc: Larry McVoy <lm(a)mcvoy.com>, TUHS main list <tuhs(a)minnie.tuhs.org>
> Subject: Re: [TUHS] was turmoil, moving to rm -rf /
> Message-ID: <20170425140853.GD24499(a)mcvoy.com>
> Content-Type: text/plain; charset=us-ascii
> Whoever was the genuis that put mknod in /etc has my gratitude.
> We had other working Masscomp boxen but after I screwed up that
> badly nobody would let me near them until I fixed mine :)
> And you have to share who it was, I admitted I did it, I think
> it's just a thing many people do..... Once :)
> From: Kurt H Maier
> /etc/glob, which appears to report no-match if the first character is .
So I couldn't be bothered to work out how 'glob' worked exactly, so I just did
an experiment: I created a hacked version of 'rm' that had the directory
handling call to glob call 'echo' instead of 'rm'; it also printed 'tried'
instead of the actual unlink call, and printed 'cd' when it changed
I then set up two subsidiary directors, foo and .bar, with one containing
'.foo0 foo1' and the other '.bar0 bar1'.
Saying 'xrm -r -f .*' produced this:
-r -f foo xrm xrm.c
-r -f foo xrm xrm.c
-r -f bar1
(This system has /tmp on a mounted file system, which is why the 'cd ..' was a
NOP. And a very good thing, too; at one point the phone rang, and it
distracted me, and I automatically typed 'rm', not 'xrm'... see below for what
happened. No biggie, there were only my test files there. The output lines
are "-r -f foo xrm xrm.c" because that's what 'glob' passed to 'echo'.)
Saying 'xrm -r -f *' produced this:
-r -f foo1
So apparently 'glob', when presented with '*' , ignores entries starting with
'.', but '.*' does not.
When I stupidly typed 'rm -r -f .*', it did more or les what I originally
thought it would: deleted all the files in all the directories (but only on
the /tmp device, because .. linked to the itself in /tmp, so it didn't escape
from that volume); leaving all the directories, but empty, except for the
files .foo0 and .bar0. So files and inferior directories with names starting
with '.' would have escaped, but nothing else.