Nebula/nebula.bin/Newsletters/GEnieUnixNews/unxnl-06.93

Text File | 1993-07-08 | 33KB | 788 lines

          _  _  _   _  _   _
         // // //| // // \//     N E W S
        //_// // |// //  /\\     Vol 4, Issue 6 - June 1993
      R o u n d T a b l e (tm)

   Items of interest to participants of the GEnie Unix RoundTable

 INDEX TO VOLUME 4, ISSUE 6:
 ===========================

 ED: editor notes - (GARS) Gary Smith
 --
  - Unix Basics Tutorial RTC's resume
  - 7000 files and counting
  - Library Survey
 NeXT Column (ERICTREMBLAY)  Eric "E.T." Tremblay
 -----------
  - Improv - Improving the Spreadsheet
 Lock and Key Unix Security (SARAH)  Sarah Collier
 ------------
  - 1st Cut of Unix Security Lore
 Foo.Bar!  Unix Humor:
 --------
  - Selecting a Programming Language Made Easy  (ANDY)  Andy Finkenstadt
 Down and Dirty: Quick Scripts that do something useful  (GARS)  Gary Smith
 --------------
  - RNELM - Reply to news articles with ELM
  - How to export variables from Child to parent
 usr/local: Items (scripts and news) snarfed from various sources
 ---------
  - shell programming report (new version)  (GARS)  Gary Smith
  -
 TUTORIALS
 ---------
  - Reclaiming Lost Data  (MIKE.NOLAN)  Mike Nolan
  - Rookie Review (JANS)  Janet McNeely
    _

 eot ------

                The RoundTable Staff is:
      ANDY          Andy Finkenstadt  Chief SysOp
      MIKE.NOLAN    Michael Nolan     Assistant SysOp
      SARAH         Sarah Collier     Administrative Assistant
      GARS          Gary Smith        Library Manager
      MIKE.MC       Mike McCabe       Linux & 386BSD Support SysOp
      JANS          Janet McNeely     Bulletin Board Manager
      LRARK         Ricky Mobley      Network Comm Liaison
      ERICTREMBLAY  Eric Tremblay     NeXT Support SysOp
      DELPHI        Brian T. Riley    RTC Conference Manager
      UNIX$         The Whole Crew


 We strongly encourage you to contact any or all of us if you have -ANY-
 comments or suggestions. This is -YOUR- RoundTable. We are here to make
 your participation as pleasant and beneficial as possible.

 LIVE Help Desks (type  MOVE 400;4 and choose channel #4):

 LIVE in-person Conferences (select #2 on the menu):

 ED: editor notes - (GARS) Gary Smith
 ==

    After a brief suspension, due to RTC SysOp Mike McCabe's business trip
 to Japan, the Unix basics tutorial RTC's (Real Time Conferences) have
 resumed on Sunday nights at 9pm Eastern.  If you have a need to learn
 Unix commands this is your opportunity to get guru level hand-holding.
 Gars recommends these with a BIG check mark for quality.

    We have achieved a bit of a landmark in the Unix Software Libraries. We
 passed the 7000 "files posted" mark and are on a fast track to 7500. If
 you haven't checked the files out lately, you are probably missing one or
 two your system could benefit from.  If there's one you want, we have
 somehow failed to post, drop us an e-mail. We'll be glad to do an archie
 search and FTP it in here for you.

    I have posted the following note in the New Files area of the Bulletin
 Board:

     Please take a moment to copy and respond to the following survey.
     Your opinion is important. We are going to base our decision 100%
     on user response.
     At issue is the posting of new library uploads to the Bulletin
     Board. This is one of the very few RoundTables that does so.
     When we first began this practice it made some sense to make
     all users aware of new files. With the rate of new file additions,
     the ability of scripting programs to automatically capture such
     lists, and the time it takes to filter through this information
     if it is not of value make the continuance of the practice highly
     questionable.
      ------------------- clip here ----------------------
     Do you wish to have the New Library Uploads Posted to the
     Bulletin Board as is now the practice?   [Y/N]
     Would you prefer No Listing, a Short Listing or a Long
     Description?                             [N/S/L]
     Mail your response to GARS.
     The vote will only be tabulated by mail and only through
     21 June 1993. At that time YOU will have made our decision.
     Thank you for your interest and participation.

   If you managed to overlook the above, please clip and respond to it
 as soon as possible.  Your opinion is important!

  Gary  [e-mail]
        [e-mail]

 eot ------

 NeXT Column  (ERICTREMBLAY)  Eric "E.T." Tremblay
 ===========
                     Improving the Spreadsheet
                          April 9, 1993
                      By Eric "E.T." Tremblay

     It all started in 1986 in the mind of a bright developer at
 Lotus called Pito Salas. He's the one who came up with the basic
 idea for Improv.Unfortunately the project was stalled for almost
 a year until Lotus hired a hot programmer named Glenn Edelson,
 whose job was to implement Salas's ideas. Improv was supposed to
 be introduced to the world under the OS/2 and Microsoft's
 Presentation Manager operating systems, but on October 1988 Steve
 Jobs visited Lotus and changed the future.

     Steve Jobs came to Lotus to show off his new computer. After
 a private meeting, the top management at Lotus decided to show
 off its newest products under development. While seeing a demo of
 Improv, Steve Jobs was getting more and more excited. Improv fit
 right in with the vision he had of his new computer. A product
 that was totally new and bold. Something that no one had seen
 before on any computer. A software the would reflect his vision
 of computing.

     Why did Lotus change their idea to developing Improv on the
 NeXT instead of on the PC? Well, there are a couple of very good
 reason for the switch.  The developers at Lotus were trying to
 build a totally new spreadsheet application on top of a buggy
 initial release of OS/2 and Presentation Manager, and having a
 difficult time because of the instability of the operating
 system. Plus, ever since the developers had seen the demo of the
 NeXT, the black machine was constantly coming back in their
 minds. They wanted to experiment with what the NeXT had to offer
 and with the level of problems they were having with the PC
 environment, the team finally decided to switch to the NeXT.
 Another key factor for the move to the NeXTSTEP environment was
 the lack of 1-2-3 spreadsheet available for the NeXT. Because
 Improv was the only spreadsheet available at the time for the
 NeXT, it would not interfere and be in conflict with 1-2-3 on the
 PC platform and Lotus would not have to explain the differences
 to it's customers. So they could take a chance with a new product
 and not run the risk of hurting the PC sales of 1-2-3. Everyone
 was a winner. Steve Jobs had a new generation of spreadsheets on
 his new computer and Lotus had the opportunity to introduce a new
 kind of spreadsheet without taking any risks.

     Improv is now available to the PC world under the Windows
 platform, Lotus is currently selling Improv for Windows at a very
 low introductory price. At this price it is a very good deal
 believe me. Please be warned that Improv is a totally new way of
 looking at spreadsheets and that the current spreadsheet experts
 are going to look like beginners when faced with Improv.

     The best way to approach Improv is to forget everything you
 know about spreadsheets and start over from scratch. Open the
 documentation and do the exercises a couple of times. The best
 way to learn Improv is to use it. I have been using Improv for
 over a year now and I'm learning something new every week.

    I keep all my personal financial information in Improv and I
 have over two years of daily financial reports for the family
 business. A good way to start is to redo an old spreadsheet in
 Improv. Please note that it is important to redo a spreadsheet
 the Improv way and not simply import an old 1-2-3 spreadsheet and
 fix it up after. A spreadsheet that is done from scratch will
 really give you the Improv advantage.  Imported 1-2-3
 spreadsheets work well, but when you import a 1-2-3 spreadsheet
 you cannot take full advantage of all the features of direct
 manipulation that Improv offers.

     Should you get Improv? Well that's up to you but would I
 change my Improv for a 1-2-3? No, way! The transition is
 difficult but when you are finally over the shock, the change is
 for the better.  When you know how Improv works, you will look at
 1-2-3 in a completely different way and only then will you
 realize the power of Improv.

    If you wish to discuss Improv for the NeXT, come and visit
 us in the Unix RT bulletin board category 16.  If you have Improv
 for Windows, you can also discuss this in the Windows RT bulletin
 board category 14 topic 7. There you will find many users of
 Improv including myself that have the experience and knowledge to
 help and guide you with Improv. Hope to see you there...

 eot ------

 Lock and Key  Unix Security:  (SARAH)  Sarah Collier
 ============

 Questions on Unix Security
   -- from the Security Digest, Volume 1, Number 063

 From:    [e-mail] (barbara.tongue)
 Subject: 1st Cut List of Unix Security Lore
 Date:    Tue, 27 Apr 1993 17:26:06 GMT

 folks,

 if someone were to come to you and ask, what are the most crucial
 aspects of unix networked security to know, what would you answer
 and in what list of priority?  here's my cut:

 1.) secure from outside machines
         a) ftp
         b) telnet
         c) nfs

 2.) secure from software holes
         a) sendmail
         b) setuid scripts

 3.) secure from users
         a) educated
         b) unknowing

 4.) ???

 i'm a tad new at this game, and decided that the best way
 to start was to ask those in the know.

 thanx in advance,


 --
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%  The Speaking Tongue, AT&T  %%  C Code.  C Code Run.  Run, Code, RUN! %%
 %%      [e-mail]      %%           PLEASE!!!!                   %%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

 ------------------------------

 From:    [e-mail] (Marcus J Ranum)
 Subject: Re: 1st Cut List of Unix Security Lore
 Date:    27 Apr 1993 21:54:20 GMT

 [e-mail] (barbara.tongue) writes:
 >if someone were to come to you and ask, what are the most crucial
 >aspects of unix networked security to know, what would you answer
 >and in what list of priority?

         I'd start off by looking at it at a higher level. First I'd
 ask myself what the possible points of attack are. Then I'd ask myself
 what security I have in place to protect each possible point of attack.
 In some cases, it may be OK to have no security for a given service,
 but you want to note that down as a form of security. ;)

         For example, if you do a 'netstat -a' on any system that might
 come under attack via the network, you'll get a listing of all the
 services you need to worry about. If you're running lots of SunRPC
 services, you'll notice a lot of upd services, and it's hard to tell
 what is what. That, in and of itself is a clue.

         Anyhow, so you get a list of services that you present to the
 world, and then check them off one by one. Another fairly important
 consideration for each service is who/what it runs as and whether
 it's privileged already. For example: sendmail. I'd put a big purple
 star opposite sendmail as a potential problem. ;)

 > here's my cut:
 >
 >1.) secure from outside machines
 >       a) ftp
 >       b) telnet
 >       c) nfs

         mountd
         NIS/yellow pages
         rwalld (some versions of rwalld permit escape codes)
         etc,
         etc

         There's a long list. I have a (well deserved) reputation on the
 net for being a paranoid. I believe that, depending on the level of
 security you require, it's sometimes best to shut all network services
 down and turn them on one by one, rather than the other way around.

         What kind of system you're going to run is a real important
 question:
         ** Is this for a firewall/gateway system, or is this for a
         general use system?
         ** Will it be exposed to external attack or only to internal attack?
         ** How important is the data on it? How much will it cost if it is
         destroyed, stolen, or modified?

         If the system is a general use system without very important data
 on it, and it's on a private LAN, obviously your security concerns are
 less than if it's a firewall system protecting a network with corporate
 sensitive data from the Internet.

         Security, outside of the context of the level of threat you need
 to deal with, and the level of risk you need to protect against, is
 meaningless.

 >2.) secure from software holes
 >       a) sendmail
 >       b) setuid scripts

         Another approach is to try to identify the types of threats that
 software holes pose, and then address those globally through policy. For
 example, setuid shell scripts come into existence because they are easy
 to write(apparently) and use. Approach a general solution by providing
 a mechanism that is secure, and solves the problem, instead of fixing
 holes. Sendmail has a bad rap because of the Morris worm. Part of the
 problem, though, is that it's a big, complex program that runs with
 privs. Depending on your mail requirements, maybe some kind of mailer
 that doesn't require privs would work. I believe MMDF solves a number
 of the security problems of sendmail, while retaining the bigness and
 complexity.  ;)

 >3.) secure from users
 >       a) educated
 >       b) unknowing

         First formulate a statement of what your users should and should
 not be able to do. Users always pose a threat. If that's OK, then figure
 out what what the limits of the threat they should be able to pose is, and
 figure out how to give them an environment that enforces that limit. This
 is not an easy problem.

 >4.) ???

         IMHO, making a list isn't the best way to start. Figure out what
 risks you're afraid of, and what the ground rules are. Figure out what you
 need to protect against and what services you need to provide. The latter
 two will be in conflict, so you have to decide which side of the spectrum
 your policy favors. Only then do you have to start listing stuff, and
 I'd approach that by splitting my paper down the middle and listing
 user requirements on one side and security requirements on the other. Then
 you're into slogging through the mud.

 mjr.

 ------------------------------

 eot ------

 Foo.Bar!  Unix Humor:
 ========

 Item forwarded  by  ANDY         to GARS
 Sub: Programming

               Selecting a Programming Language Made Easy
                   Daniel Solomon & David Rosenblueth
         Department of Computer Science, University of Waterloo
                   Waterloo, Ontario, Canada N2L 3G1

    With such a large selection of programming languages it can be
 difficult to choose one for a particular project. Reading the manuals to
 evaluate the languages is a time consuming process. On the other hand,
 most people already have a fairly good idea of how various automobiles
 compare. So in order to assist those trying to choose a language, we
 have prepared a chart that matches programming languages with comparable
 automobiles.

 Assembler     - A Formula I race car. Very fast, but difficult to drive and
                 expensive to maintain.
 FORTRAN II    - A Model T Ford. Once it was king of the road.
 FORTRAN IV    - A Model A Ford.
 FORTRAN 77    - A six-cylinder Ford Fairlane with standard transmission and
                 no seat belts.
 COBOL         - A delivery van. It's bulky and ugly, but it does the work.
 BASIC         - A second-hand Rambler with a rebuilt engine and patched
                 upholstry. Your dad bought it for you to learn to drive.
                 You'll ditch the car as soon as you can afford a new one.
 PL/I          - A Cadillac convertible with automatic transmission, a two-
                 tone paint job, white-wall tires, chrome exhaust pipes, and
                 fuzzy dice hanging in the windshield
 C             - A black Firebird, the all-macho car. Comes with optional
                 seat belts (lint) and optional fuzz buster (escape to
                 assembler).
 ALGOL 60      - An Austin Mini. Boy, that's a small car.
 Pascal        - A Volkswagon Beetle. It's small but sturdy. Was once
                 popular with intellectuals.
 Modula II     - A Volkswagon Rabbit with a trailer hitch.
 ALGOL 68      - An Astin Martin. An impressive car, but not just anyone
                 can drive it.
 LISP          - An electric car. It's simple but slow. Seat belts are not
                 available.
 PROLOG/LUCID  - Prototype concept-cars.
 Maple/MACSYMA - All-terrain vehicles.
 FORTH         - A go-cart.
 LOGO          - A kiddie's replica of a Rolls Royce. Comes with a real
                 engine and a working horn.
 APL           - A double-decker bus. Its takes rows and columns of
                 passengers to the same place all at the same time. But, it
                 drives only in reverse gear, and is instrumented in Greek.
 Ada           - An army-green Mercedes-Benz staff car. Power steering,
                 power brakes and automatic transmission are all standard.
                 No other colors or options are available. If it's good
                 enough for the generals, it's good enough for you.
                 Manufacturing delays due to difficulties reading the
                 design specification are starting to clear up.


 eot ------

 Down and Dirty: Quick Scripts that do something useful  (GARS) Gary Smith
 ==============

 RNELM - Reply to news articles with ELM
 ---------------------------------------
 From: [e-mail] (Cliff Tuel)
 Subject: Rnelm -- reply to news articles with ELM

 This is one of those "why didn't I think of that" programs: when
 pressing 'R' or 'r' in rn or trn to reply to an article by mail,
 you get thrown into ELM, instead of mail.  See the comments for
 instructions.

 --- cut here ---

 : to unbundle, "sh" this file -- DO NOT use csh
 :  SHAR archive format.  Archive created Mon May 17 16:57:36 1993
 echo x - Rnelm
 sed 's/^X//' > Rnelm <<'+FUNKY+STUFF+'
 X#!/bin/sh
 X#
 X# Rnelm -- use ELM to reply to news articles
 X# Cliff Tuel, [e-mail]
 X# May 17, 1993
 X#
 X# To make (t)rn call this instead of Rnmail: setenv MAILPOSTER Rnelm
 X#
 X
 Xletter={$DOTDIR-$HOME}/.letter
 Xorig={$DOTDIR-$HOME}/.rnhead
 X
 Xumask 66
 X
 Xto=`grep "^To: " $orig | head -1 | sed -e 's/^To: //'`
 Xsubject=`grep "^Subject: " $orig | head -1 | sed -e 's/^Subject: //'`
 X
 Xrm -f $letter
 Xsed -e '1,/^$/d' < $orig >> $letter
 Xelm -i "$letter" -s "$subject" $to
 Xrm $letter
 +FUNKY+STUFF+
 echo '-rwxr-xr-x   1 ctuel    staff    480 May 17 1993  Rnelm    (as sent)'
 chmod u=rwx,g=rx,o=rx Rnelm
 ls -l Rnelm
 exit 0


 --
 __o o__  Cliff Tuel, System Admin
 \( v )/  Departments ARDFA, CE/ENVE      ART OF NOISE, YELLO mailing lists
  /___\   Cal Poly, San Luis Obispo       [e-mail]
   ^ ^    [e-mail]      [e-mail]

  eot ------

 How to export variables from Child to parent
 --------------------------------------------

 From: [e-mail] (Ron Wigmore)
 Subject: Re: How to export variables from Child to parent

 >I am writing a small shall script. I want to invoke a child process by
 > program and the program changes some of the variables.
 >
 >How can I check the changes variable. I can used exit # and check the # .
 >If there is any other way to check the variables, please send me a note ...

 This is easy to handle if you are using Bourne/Korn shells.  Simply use
 shell functions instead of separate shell scripts. eg.

 grand_daughter() {
 echo Hi ma!   Hi grandma!
 daughter
 mother
 }
 daughter() {
 echo Hi ma!  Hi daughter!
 }
 mother() {
 echo Hi children!
 }
 mother
 daughter
 grand_daughter
 exit

 Functions really make shell programming easier, although they are
 not supported by all shells.  The "{" and "}" are actually the curly
 braces that VM likes to display as hypens!  Functions act a lot like
 "Call Routines" in REXX ie. you do not have to worry about "results"
 not being passed to the "caller", since a new process is not created
 when the shell function is invoked, everything available to the "caller"
 is available to the function and visa versa.  You don't have to worry
 about exporting variables either.  :-)

 Ron,,,


  eot ------

 usr/local: Items (scripts and news) snarfed from various sources
 =========

 shell programming report (new version) (GARS)  Gary Smith
 -------------------------------------

 From: [e-mail] (Mario Nigrovic)
 Subject: Re: shell programming report (new version)

 In article <1993May7.031135*[e-mail]>,
                              [e-mail] writes:
 !  I got many answers for my answers, thank you all. follow is my report:
 !
 !  1. rm output
 !     exec > output     ******** only this works ***********
 !
 !       report: work under "sh", dont work under "csh"
 !               "csh" told me:   exec: too few arguments
 !
 !  2. cp /dev/null output
 !       report: dont work under "csh" & "sh"
 !               the file output will be filled by NULL, so size still large
 !
 !  3. > output
 !       report: dont work under "csh" & "sh"
 !               the file output will be filled by NULL, so size still large
 !
 !  4. rm output
 !     touch output
 !       report: dont work under "sh" and "csh"
 !
 !
 ! So,it is obvious that there is a command just work under sh.Unfortunately,
 !I use "csh".... Any one have solution using "csh"??  Or I have to change
 !the shell I use...

 |>
 |> To bad people that responds doesn't seem to know better.  If I remember
 |> the thread correctly, the issue were about nulling out a file, and the
 |> following should work globally (in whatever *ix shell):
 |>
 |>    : >file
 |>
 |>
 |>   ~~h

 Anyone else just a little curious about (2) above?  That seemed to me to
 be the way to solve the problem, too.  But, trying it, I realized that no
 matter what you do, you can't reset the csh's write pointer into it's
 output stream.

 Still, writing past the end of a file is the conventional way to create
 holes  in a file.  This has been done as copy-protection by sun in the
 past.

 Conclusion: (2) works, but doesn't look like it.

 Explanation:  Unix can create files with large apparent sizes but
 minimal allocated sizes.  When any program attempts to read an
 un allocated section of the file, it gets... nulls.  The only way I
 know to directly determine the allocated size of a 'holed' file is
 via dump.  Consider the following script:

 #! /bin/csh -f

 @ count=1

 while ( $count < 2000 )
    if ( $count % 25 == 0 ) cp /dev/null output
    echo "$count this is a large amount of text.  Please let me know."
    @ count++
 end

 This produces a seemingly large output file:

 % ls -l output
  -rw-rw-r--  1 mario      114835 May 10 12:36 output

 But the difference in 'df .' before and after is only 24K!

 To verify, I ran 'dump':

 % dump 0f output.dump output   # (Yes 'mario' is in group 'operator')
   DUMP: Date of this level 0 dump: Mon May 10 12:40:00 1993
   DUMP: Date of last level 0 dump: the epoch
   DUMP: Dumping /dev/rsd0d (/local) to output.dump
   DUMP: mapping (Pass I) [regular files]
   DUMP: mapping (Pass II) [directories]
   DUMP: estimated 118 blocks (59KB) on 0.00 tape(s).
   DUMP: dumping (Pass III) [directories]
   DUMP: dumping (Pass IV) [regular files]
   DUMP: Tape rewinding
   DUMP: 96 blocks (48KB) on 1 volume
   DUMP: DUMP IS DONE

 Unix 'cp' is not as smart as dump at avoiding 'holes', so to
 verify, I copied the file and ran dump again...

 % cp output output2
 % dump 0f output2.dump output2
   DUMP: Date of this level 0 dump: Mon May 10 12:41:59 1993
   DUMP: Date of last level 0 dump: the epoch
   DUMP: Dumping /dev/rsd0d (/local) to output2.dump
   DUMP: mapping (Pass I) [regular files]
   DUMP: mapping (Pass II) [directories]
   DUMP: estimated 296 blocks (148KB) on 0.00 tape(s).
   DUMP: dumping (Pass III) [directories]
   DUMP: dumping (Pass IV) [regular files]
   DUMP: Tape rewinding
   DUMP: 304 blocks (152KB) on 1 volume
   DUMP: DUMP IS DONE

 Quite a difference, eh?  Looking at the dump outputs...

 % ls -l *dump
 -rw-rw-r--  1 mario       40960 May 10 12:40 output.dump
 -rw-rw-r--  1 mario      153600 May 10 12:42 output2.dump

 So we may reasonably conclude that, while apparently large,
 the output file's data could potentially be small.

 The only limit here is that the apparent size has a limit of
 2GB or so, totally independent of the size of the actual data.

 Oh, yes.  Make sure you use dump(8) for backups, not any
 program which will expand all those nulls!

                                                 Mario      **NEW**
                                                              \|/
 Mario Nigrovic <[e-mail]>    *NEW* voice: [phone]
 Motorola Western MCU Design Center        *NEW* fax:   [phone]
 *  -  -  -  -  -  -  -  -  -  -  -*-  -  -  -  -  -  -  -  - /|\ -  *
 "I just need enough to tide me over until I need more."
        -- Bill Hoest
 *  -  -  -  -  -  -  -  -  -  -  -*-  -  -  -  -  -  -  -  -  -  -  *


 eot ------

 UnixNews  (DELPHI)  Brian T. Riley
 --------

 eot ------

 TUTORIALS
 =========

 Reclaiming Lost Data, or, Oops!  (MIKE.NOLAN)  Mike Nolan
 -------------------------------

 There are certain commands in Unix that are so powerful that they are
 downright dangerous.  'rm' is one of them.

 Recently I was trying to create some additional file space on a tight
 system by cleaning up some old unused directories and did 'rm -rf *' to
 delete all the files in one directory tree.  This removed all the
 non-hidden files, leaving files like .profile, .newsrc, etc.

 So, without thinking much, I typed 'rm -rf .*'.  Unfortunately, this not
 only deletes the files in the current directory tree, but in the
 parent ('..') directory tree as well.  I figured it out before it deleted
 the ENTIRE parent directory (which was /home, the primary user directory
 in SVR4), but it did manage to delete around 120MB of data files.

 A quick check of the unix FAQ (in news.answers) confirmed my suspicion
 that the data was not easily recoverable.   However, the FAQ goes on to
 suggest that if the system can be halted IMMEDIATELY it might be possible
 to reclaim some of the data.  Although I think this comment is tied to
 halting the system without rewriting the superblock (where the inode
 information is stored), it did get me to thinking about HOW Unix stores
 (and deletes) files.

 Although the particulars vary depending on what filesystem type you have
 (UFS, BFS, System V, etc.), in general files in a Unix filesystem are
 identified by their inode number, and there are links to these inodes
 that indicate where the file is placed in the directory tree structure and
 what the file name is.  An active inode has at least one link entry to it,
 and can have many more.  When a file is deleted, the link and inode
 information is deleted, but the data contents of the file are not erased.
 (This may not be true on secure systems.)

 So, my 120MB of data was still out there, and as long as I didn't write on
 those blocks there was a chance I could reclaim the data, or at least some
 of it.  So, I disconnected this system from the rest of the network, to
 prevent most file activity.

 The first step was to figure out HOW to access the deleted data.  Unix
 devices are accessible two ways, by blocks or as streams of characters.
 In the /dev directory, block special files are identifiable by a 'b' in
 the first position of the long (ls -l) entry, and character special files
 by a 'c'.  A character special file is also sometimes called a 'raw' file
 because Unix will consider it as a continuous stream of characters.

 So, I wrote the entire raw disk image to a streamer tape. (I used the
 command: 'dd if=/dev/rroot of=/dev/rmt/c0t3d0s0')  This took about two
 hours, because the partition involved had 700,000 blocks on it, and
 streamer tapes are generally not noted for their speed.

 Now that I had a copy of the data in a non-volatile form, I had to figure
 out how to locate and reclaim the missing information.  (By this time I
 had determined that at least 90MB of the missing data was sample data for
 a project I'm working on, easily regenerable.  However, most of my programs
 and shell scripts would be much harder to reproduce.  This system is not
 yet in production mode, so we had not yet set up a meaningful backup
 schedule.)

 Using an existing program as a starting point, I developed 'reclaim', which
 takes the information from the streamer tape, processes it in 512 character
 blocks, and looks for my missing data.  Two keys to making this work was
 having some idea of what was IN the missing files, and the realization that
 since only TEXT blocks needed to be examined, I could skip any blocks that
 were non-text.

 Reclaim examines each block to see if it has non-ascii characters in it.
 (IE, greater than 177 octal, or below 040 octal, except for new line, tab,
 new page, and perhaps a few others.)  Within a valid text block, reclaim
 searches for specific character strings that would be part of the data.
 (The search strings are currently hard coded into the program, although it
 would be possible to have them input from the keyboard or from a data file.)
 The output consists of the block number, followed by the 512 characters of
 text.

 Each pass with reclaim takes me at least 90 minutes, more if it finds lots
 of data.  Some forethought needs to go into determining what characters
 sequences to search for.  (One would NOT want to search for the string
 'char',  for example, but 'char my_weird_variable_name' might work.

 I quickly determined that for the most part my programs and scripts tended
 to be in consecutive blocks, and so added to reclaim the option to save
 text blocks that are 'close' to blocks with matching  character strings. It
 also helps to specify more than one string that will appear in a target
 file, because the first string might overlap two blocks.  An additional
 refinement that could be added to reclaim would be a regular expression
 search, but that is a LOT more work!

 Anyway, the good news is I've been able to reclaim the most important parts
 of my lost data, and I'm holding on to the tape for a while.

 The current version of 'reclaim' has been uploaded to the Unix RoundTable
 library, and will be available as file # 7136.  I hope nobody ever needs to
 use it, though!

 eot ------

 Rookie Review  (JANET.S)  Janet McNeely
 -------------
 Part 5 of a continuing series


 eot ------

  ---------------
  REMINDER - This newsletter is being sent to you 'by request'. If you do
 not wish to keep receiving it, e-mail a stop notice to GARS. On the other
 hand, we would very much appreciate it if you would pass the word that we
 do distribute this item near the tenth (10th) of the month of issue to any-
 one on GEnie who requests it.
   P L E A S E  also remember contributions are most welcome. Please e-mail
 items and/or suggestions to GARS.

 etx ------


 Trademark and Copyright notices:
 Unix is a Trademark  of UNIX System Laboratories, Inc.; GEnie, LiveWire, and
 RoundTable are Trademarks of General Electric Information Services  Company;
 Xenix and ms-dos are Trademarks of  Microsoft  Corporation; NeXT NeXTstation
 and NeXTstep  are Trademarks  of  NeXT Computer Systems, Inc., Coherent is a
 Trademark of Mark Williams Company, Sun, SPARC, SunOS are Trademarks of  Sun
 Microsystems, Inc., SCO is a Trademark of  Santa Cruz Operations, Telebit is
 a Trademark of Telebit Corporation, Hayes  and  Smartmodem are Trademarks of
 Hayes Microcomputer Products, Inc.

 The contents of this newsletter are copyright(c) 1992 and may be copied whole
 or in part only if original  credit is included. The GEnie UNIX RoundTable is
 not affiliated with AT&T or UNIX System Laboratories, Inc.

 eof ------