			      LREAD  3.3
Programm to read LINUX Extended2-Filesystems on PCs from within DOS/Windows
		    or from UNIX operating systems

			Original version 1.0 written by
  Jason Hunter and David Lutz at Willamette University, Salem, Oregon, USA

			Version 2.x and newer modified by
		  Werner Zimmermann, FHTE Esslingen, Germany


	Revision 2.x and newer are released to public under the GNU GPL license,
	see file COPYING. You are using the program on your own risk.


Contents:
	1. Usage
        2. Graphical User interface LREADsrv
	3. Configuring and Compiling LREAD
	4. Known Problems and To Do List, Help Wanted
	5. Running the LREAD tools under UNIX and QDOS
	6. History
	7. Acknowledgements
	Appendix: lread10's original README.TXT
		 

1. Usage

If you want to run the LREAD tools under DOS/Windows, you'll find all
binaries and all support files in subdirectory ./bin.
If you want to run the LREAD tools under a UNIX operating system, binaries
and support files are under ./bin.unx; but please read this section *and* 
section 5 first.

The package comes with executables ready to run under DOS or in the DOS
box of Windows 3.1, 95, 98:
	ldir.exe      list directories and files
	lread.bat     read and copy files from Linux to DOS
	lwrite.bat    copy files from DOS to Linux
	ldel.bat      delete Linux files
	lchange.bat   change Linux file attributes and owner

One additional executables provides the same functionality under Windows NT:
	ldirNT.exe    
This file is not called directly by the user but is called indirectly via
ldir.exe, when ldir.exe detects Windows NT. 
In order to read the harddisk under Windows NT you need administrator rights.

Executable and supporting files are in directory ./bin.

The programs have various parameters and options:

ldir [-h | -v | -? | -part] [-s/dev/hd..] [Linux_Directory]

	* lists a ext2-directory like DOS' dir or Linux's ls.
	* -h  print help info
	* -v  print version info
	* -s  specify the harddisk partition on which the ext2-directory is
	      eg. /dev/hda5. The default value is set in ldir.h (see 2.)
	      or via environment variable LDRIVE=/dev/.... (see below).
	      Floppy disk drives /dev/fd0 and /dev/fd1 are also supported.
	      If you only specify /dev/hda or /dev/hdb, i.e.. no partition number,
	      ldir will search for the first Linux partition on that drive.
	      Please note, that without parameter -s/dev/... ldir will only
	      search the harddisk which was preconfigured when it was compiled
	      (usually /dev/hda, i.e. your first (primary) IDE harddisk) or
	      which is set via environment variable LDRIVE (see below).
	      You may also specify SCSI harddisks, e.g. /dev/sda, or partitions
	      on these disks as /dev/sda3.
	      If you're using a mix of IDE and SCSI harddisks, see 3.
	      If you do not know, on which drive and partition your Linux file-
	      system resides, use 'ldir -part' (see below);
	* -part scans all harddisks and lists all partitions with partition
	      type and length. When specifying -part, all other parameters
	      are ignored.
	* Linux_Directory is the directory you want to list, if you omit it,
	  the root directory '/' is listed. You can also specify a Linux_File
	  instead of a directory. The name must be a valid Linux name, i.e
	  path delimiter is '/' (not '\'!), all names are case sensitive. For
	  using wildcards see below. If Linux_Directory ends with '/', the
	  contents of the directory is listed.

lread [-h | -v | -?] [-s/dev/hd..] Linux_File [DOS_File]
	
	* lists a Linux file or copies it to DOS
	* -h  print help info
	* -v  print version info
	* -s  see ldir
	* Linux_File is the name of the Linux file including the path, if
	  necessary. Pathnames are specified in UNIX style, i.e. with '/'
	  instead of DOS's '\', eg. /usr/src/linux/Documentation.
	  See below how to use wildcards.
	* DOS_File is the name of the file after it is copied, it must be a
	  valid DOS filename. Long filenames (more than 8+3 characters) are
	  only supported, when you operate under Windows95 (and newer) and
	  when your binary is compiled by Turbo/Borland C. If you do not
	  specify DOS_File, the Linux_File is listed to stdout (normally the
	  screen) instead of copied. If you specify '.' as DOS_File, the
	  copy will have the same name as the Linux_File (if not operating
	  under Windows95 the filename will be cut to 8+3 characters!)

	  When specifying filenames, remember, that Linux path- and file-
	  names are case sensitive, whereas DOS names are not.

Using wildcards:
	  You may use wildcards '?' and '*'. Wildcards are supported in
	  DOS style, not UNIX style, i.e. '*' stands for 'rest of the name
	  - until the next '.' does not matter'. Unfortunately there are some 
	  restrictions:
	    - If you use wildcards in a pathname rather than in a filename,
	      only the first matching directory is shown.
	    - When you want to copy multiple files by using wildcards, you
	      must specify '.' as destination (or leave blank to copy to 
	      stdout). Files, for which the Linux_File-name is not a valid 
	      DOS_File-name cannot be copied using the '.' option, for those 
	      you must explicitly specify a DOS_File-name.

The programs respects the following environment variables:
  LDRIVE=/dev/...
	  Specifies the default drive. Set this environment variable via
	  DOS-command 'set LDRIVE=/dev/...'. This option overrides the
	  default disk drive set during compilation in ldir.h and itself
	  may be overridden by command line option '-s/dev/...'.

  LDIR=LinuxPath
	  Whenever a linux-filename on the command line does not start
	  with '/' the LinuxPath given in this environment variable is
	  prepended. You may set this environment variable via the batch
	  file lcd.bat using 'lcd <LinuxPath>'.
	  Please note: Linux/Path must begin with '/'.

!!!!!!!!!!!!!!!!!!EXPERIMENTAL!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Starting with version 2.7 experimental write support is provided. In the moment
this is strictly experimental, permanent damage to your disk is possible, so
backup your data before and use at your own risk !!!
All write operations will set your Linux filesystem to 'not clean'. On most
systems this will cause fsck (e2fsck = file system check) to run during the 
next Linux reboot, to see if your filesystem is OK.

Write support in the moment only works under DOS or Windows NT. In Windows
9x's DOS boxes we have to lock the harddisk. This 'lock' needs a floppy
disk to be inserted, even if you do only access a harddisk. This strange
behaviour is not yet solved.

The syntax is

ldel [-h | -v | -?] [-s/dev/hd..] Linux_File
	      Delete the specified file! 

lchange [-h | -v | -?] [-s/dev/hd..] [-fFMODE] [-uUID] [-gGID] Linux_File
	      Change the file mode, user and group identifier 
	      -f change the file mode (access rights), like Linux's chmod; FMODE must an
		 octal value
	      -u change user id , like Linux's chown; UID and GID must be numeric values
	      -g change group id, like Linux's chown; UID and GID must be numeric values

lwrite [-fFMODE] [-uUID] [-gGID] DOS_Path\DOS_File Linux_File
	      Copy the specified file! 
	      -u, -f, -g see above

Wildcards are not yet supported for 'lwrite -copy' and lwrite -del'.

!!!!!!!!!!!!!!!!!!END EXPERIMENTAL!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


2. Graphical User Interface LREADsrv

Starting with version 3.2, a graphical user interface is provided:
                        LREADsrv.exe
LREADsrv does not directly provide the user interface, it only simulates
a HTTP-server, to which you can connect your favorite web browser. 
LREADsrv uses some GIF and HTML files (filenames 'ZZZ...gif' and 'ZZZ...htm'),
these files must be in the directory in which LREADsrv was started from.
By default, those files all are in the ./bin subdirectory.

Please check first, if the command line tools work, before trying out LREADsrv
and set your environment variable 'LDRIVE' appropriately (see above).
Then start the server by typing   LREADsrv   on the command line and connect 
your web browser to 'http://localhost'. Click on the blue HELP button, to get 
further help about using and configuring LREADsrv, especially on how to allow
connections from remote hosts.

This simple approach won't work, if another HTTP-server is already running on
your machine. In that case open the help file 'ZZZhlp.htm' directly with 
your webbrowser. Note: As LREADsrv uses a special syntax for 'internal' re-
sources, no icons (images) will show up in the help file, if you open the
help file directly.

LREADsrv does not run, if you do not have TCP/IP installed!

When running LREADsrv, please be aware, that this still is ALPHA software.
There are some known problems:
*Internet Explorer and Netscape Navigator do not like each other... When running
 both of them several times (one after the other) without restarting LREADsrv, 
 Internet Explorer seems to slow down considerably, whereas Netscape Navigator does 
 not change its behaviour. From time to time Internet Explorer regains its normal 
 speed only after rebooting Windows. I assume, that the reason lies in my 
 implementation of the HTTP protocol. Internet Explorer by default uses
 HTTP/1.1, Netscape and my implementation use 1.0. According to the HTTP speci-
 fication I try to force Internet Explorer to use 1.0, too. Basically this seems
 to work, but may be, there are subtle problems involved. In the moment I have
 no idea (and thus no plans) to have a closer look. Maybe, sometime I should 
 have a detailed look into the Winsock and HTTP documentation. I have to admit,
 that I did not study the manuals, but relied on common sense, the SDK's online
 help and my (hopefully) basic understanding about how UNIX sockets work. The
 rest was a trial and error approach ...

*LREADsrv does not allow multiple users in parallel, as it is only a single threaded
 application.  It does not lock files and relies on global variables, rather than 
 on separate variables for each instance. When multiple users access LREADsrv at the 
 same time, it seems to them, that they can look at the directory at the same time. But if
 one user changes the current directory or the default LINUX drive, this change will
 be effective for all other users too. If one user tries to write or modify a file and 
 one of the other users changes the current directory at the same time, garbage can 
 occur. I tried to implement all file modify and write operations stateless, but as
 I did not really test multi user behaviour, I'm sure, that this is far from perfect.
 This of course is no problem, if you do not allow remote access, as Windows 
 is no multi user system and I can't imaging anybody using too web browser sessions 
 at the same time. I do not plan to make LREADsrv a multithread program. So if this
 really is a problem for anybody, I'll include a lock feature, which denys access to
 more than one user at a time. The problem with HTTP is, that (at least in HTTP 1.0)
 connections are opend and closed for single data transfers. So after each connection
 a timeout would have to be defined before allowing another connection from a different
 machine (identified by its IP name). 
 
*LREADsrv's error checking is very, very weak. Most user input (filenames etc.) is
 directly transferred to LDIR. LDIR's checking is better, but LDIR's error messages 
 show up in LREADsrv's console window and I have not implemented a clean way of 
 transferring them back to the web browsers window. In some cases (file write or
 modification), the user will only notice, that a file, he wanted to copy, does 
 not show up in the directory listing or a file property was not changed, but 
 dos not get a notice about what was wrong. In other cases, LDIR's error message
 will show up in the browser window strangely formatted, as LREADsrv thinks it is
 reading a directory listing instead. In some extreme cases LDIR does not shutdown
 gracefully on errors (in all cases, where DOS does its own error handling, e.g.
 if a file on a DOS path is not found). In these cases DOS (i.e. Windows DOS box)
 'crashes' LDIR. As in the current implementation LDIR is run as a subprocess
 of LREADsrv this also crashes LREADsrv. The solution is clear (running LDIR
 in a separate process), but waits to be implemented ...
 

Some technical issues about LREADsrv, you might want to know:

LREADsrv waits in an endless loop for an incoming Winsock connection to its default 
TCP/IP port. It reads the incoming data as an ASCII character stream and interprets
them as HTTP/1.0 commands. Currently only the GET and POST commands are implemented.
If a GET command is received, its parameter is checked. If the parameter ends with 
a '/', the parameter is interpreted as a Linux pathname and we assume, that the user
wants to get a directory listing. An LDIR command for that pathname is issued via a 
system()-command (should use CreateProcess, but system() was easier to handle), LDIR's 
output will be redirected to a file named 'ZZZ.ZWZ'. This file will be read by LREADsrv, 
translated into HTML and send back to the web browser. Then, according to HTTP/1.0, the 
connection will be closed by LREADsrv. Filenames in the directory listing will be marked
(appending one character to the filename) according to their type. This mark ('/' for di-
rectory, '@' for symbolic links, '>' for device files, ' ' for normal files) normally
will be invisible for the user.

If the GET parameter does not end with '/' (or any of the other mark characters, we assume 
that the user wants to read a file. An LDIR -READ command is issued and the LINUX file is 
copied to DOS, the resulting file (again 'ZZZ.ZWZ') is then send to the web browser 
(without translation, but based on the LINUX filename extension LREADsrv tries to find 
out the file type and sends an HTML Content-Type message back to the browser). If the 
parameter ends with '@' or '>', a HTML file will be send instead, because LDIR fails
under certain circumstances with symbolic links and cannot read device files.

Filenames starting with /ZZZ.... have a special meaning to LREADsrv. These filenames are
used for resources or internal control. '/ZZZ...htm' contains screen dialogs, '/ZZZ...gif'
contains icons and buttons. If such files are requested, these files are read from the DOS
directory, from which LREADsrv was started, rather than from LINUX. If you want to
modify LREADsrv's user dialogs or icons, you can simply edit these files, e.g. ZZZwri.htm
contains the dialog for copying files from DOS to LINUX. You can change whatever you like
as long as you do not change the file's name and the name of the input variables. If
you want to add new input variables, you also have to modify LREADsrv's source code!

If you look into the /ZZZ...htm files, you will notice strange text starting with 'ZWZ...'
and ending with '...WZW' like ZWZcurrentLINdirectoryWZW. When such a file is read by 
LREADsrv, this text is dynamically substituted by the current value of some internal 
variable, e.g. by the current Linux working directory. Thus we have dynamic HTML here !
You can use all currently defined dynamic variables (look into LREADsrv's source code),
but if you want to define new ones, you also have to modify the source code, otherwise
they simply will be ignored.

POST messages are used for our 'CGI' interface, i.e. information from the web browser,
i.e. values the user has entered in the ZZZ...htm screen dialogs are transferred to 
LREADsrv. The POST message requests a file of the form /ZZZ...exe and has additional
parameters in the messages body. These requests are processed by internal functions like,
e.g. copyFileExecute(). The processing itself is done like in standard CGI programs,
except that we do not communicate with environment variables.



3. Configuring and Compiling ldir and lread

Before you compile them, edit ldir.h to configure the default name of your
ext2 Linux partition and the timezone value (see the comments in ldir.h).
The Linux partition name is any valid Linux harddisk device, e.g. /dev/hda2 
(second partition of your first harddisk) or /dev/hdb6 (second logical par-
tion on an extended partition on your second harddisk). If you have SCSI
harddisks, you may also specify partitions on SCSI disks, e.g. /dev/sda3.
If you use a mixture of IDE and SCSI drives, please see 3.
If you only specify /dev/hda or /dev/hdb, i.e. without the partition number,
ldir/lread will search for the first Linux partition on this harddisk.
Floppy disk drives /dev/fd0 and /dev/fd1 are also supported. 

If you want to recompile ldir/lread in directory src a makefile is provided. Do a
						make
to recompile with Borland C 16bit compiler (tested with BC 3.1, 4.5 and 5.0).

If you want to use ldir under Windows NT, you have to edit 'makefile'
Comment out the line 'CC=bcc' and uncomment line 'CC=bcc32'. Then do a
						make
to recompile with Borland C 32bit compiler.

In all cases maybe, you have to slightly modify the makefile before to
adapt for different pathnames on your system. All runtime files (binaries, 
batch files and some resources files will be in directory .\bin.

LREADsrv is in directory .\http. Again edit 'makefile' and do a
						make
Binaries and runtime files will be in .\bin.                                               



4. Known Problems and To Do List, Help Wanted

Harddisk Detection with IDE harddisks
To detect a ext2 harddisk partition ldir/lread read the harddisk partition 
table and relys on the standard table structure. Some boot managers and 
especially harddisk managers like e.g. the Online Track Manager, which are 
used to support harddisks >504MB with an old ROM BIOS, may modify the par-
tition table in a non-standard way. If ldir/lread has problems detecting your 
disk, please enable #ifdef DEBUG_READDISK in ldir.h and recompile it. Now ldir
will print out the partition table's contents. Mail me the results, describe
your harddisk setup and I'll try to modify the code accordingly.

Harddisk Detection with SCSI harddisks
For reading the disk's partition table, ldir/lread rely on BIOS commands. If 
your SCSI drive can be read under DOS, it should have an extension BIOS, which
should be compatible with ldir/lread. If you only have SCSI harddisks (no IDE
disks), that should work fine by simple specifying  '-s/dev/sdXY' or compiling
ldir/lread with the appropriate setting in ldir.h (X is a letter, specifying the
disk (a=first, b=second harddisk), y is a number, specifying the partition num-
ber with the ext2-filesystem).
If you have a mix of IDE and SCSI harddisks, things are a little difficult,
because Linux handels partition and disk numbering different than DOS. Rudi
Hoekema (rudi@cardio.azn.kun.nl) has done some testing for me. Here is, what
he found out:
      for your first  harddisk use '-s/dev/hdaY' or '-s/dev/sdaY'
      for your second harddisk use '-s/dev/hdbY' or '-s/dev/sdbY'
independent, what the disk's name under Linux is! Only 'Y' still is the
original Linux partition number.
There is still not so much experience with such configurations, so please mail 
me the results. If you run into problems, please enable #ifdef DEBUG_READDISK 
in ldir.h and recompile it. Now ldir will print out some diagnostics info. 
Mail me the results, describe your harddisk setup, maybe it is possible to 
modify the code accordingly.

Floppy Disk Support
Was included as a quick hack, to support the future development of also wri-
ting to ext2-filesystems (it is not so much pleasure, to crash harddisks :-))
Floppy support was not thoroughly tested.

Bugs
Well no bugs, only a bundle of 'features' :-) . ldir/lread's first version was
release to the public some three years ago. In the meantime it -hopefully- was
intensively tested by its users, but also some major parts were revised and 
significant functionality (and thus new bugs?) were added. In the last year
user's bug reports dropped to such an insignificant level, that one must assume
that nobody is using ldir/lread anymore - or that all bugs really have been 
removed :-)).
Anyway, with version V2.7 we added Lwrite, so that chances are good, that the
bug report rate will increase again ...

I assume, that there still are quite a lot of old and new bugs. So please feel 
free to help correct them. Mail me the problem and preferably a bug fix.

If you happen to have a bug, please edit ldir.h and uncomment the 'defines
reading '#define DEBUG_....', then recompile and run again, redirecting
all debugging output to a file. Have a look at the file searching for
'errors' and 'warnings'. Send me this file together with a detailed des-
cription which command(s) you used and who your system is setup (operating
system, disk types, partition types ...).


To Do List
* improve handling of symbolic links. ldir today shows links, but does not
  follow them. lread can read files via a symbolic link, if the link repre-
  sents a file name referring to the same directory but does not follow a
  linked directory path.
* better support for wildcards in path- and filenames
* ldir and lread try to read directories and files incrementally. Neverthe-
  less the block group list needs a permanently allocated buffer on the heap
  and read_inode needs a buffer allocated on the heap, which's size is depen-
  dent on the size of the inode. With directories, which hold an extremely 
  big number of files, theoretically this can be a problem with small real 
  mode memory models like TINY or SMALL. Therefore ldir comes precompiled in
  memory model COMPACT. Nevertheless the author has sucessfully tested ldir/
  lread with directories containing up to 1400 files in memory model TINY
  without having problems. So the rewrite of the memory allocation stuff
  and carefully freeing all buffers as soon as possible, seems to be quite
  successful.

You are invited to help me. If you want to contact me or simply sent bug re-
ports, or even better bug fixes, you can reach me by Email:

	       Werner.Zimmermann@fht-esslingen.de



5. Running the LREAD toolsuite under UNIX and QDOS

In subdirectory ./bin.unx you'll find binaries for running the LREAD tools
under LINUX (x86). For other UNIX like operating systems you have to compile
the tools yourself. Go to directories ./src and ./http and do a 
		make -fmakefile.unx
All binaries and support files will be copied to directory ./bin.unx. The tools 
were successfully compiled and tested under LINUX (Intel x86), LINUX-68K (Moto-
rola 68xxx) and Sun Solaris. With minor modifications they should compile and 
run under most UNIX-like operating systems.

What is this good for? Well, if your running under Solaris or any non-LINUX UNIX
system, the situation is like under DOS/Windows. You may like to access files on 
your LINUX extended2-partition. If your are running LINUX itself, LREAD can be 
compared to the MTOOLS. If you need permanent access, you're better off with 
really mounting the disks, but when you only need occassional access, LREAD
(or the MTOOLS) are an alternative.
		
Nevertheless, UNIX support was not the major design goal and it's test status
is lousely. UNIX support is maintained by Richard Zidlicky, who is also porting
the tools to QDOS. If you have any problems with LREAD on UNIX or want to report 
successful operation or if you port it to another operating system, please send 
feedback to Richard:
		<rdzidlic@geocities.com> 
or		<rdzidlic@cip.informatik.uni-erlangen.de>

But please do not forget to send a copy of your mail to 
   		Werner.Zimmermann@fht-esslingen.de

The most likely reasons for problems under UNIX are:
* You need to convert the DOS text format (CRLF sequences) to the UNIX format.
  You can do this either with 'dos2unix' or by unzipping the package
  with 'unzip -t' .
* You need to edit makefile.unx, if you do not use GNU's gcc for compilation.
* Check if filenames (sources and binaries) are in lower case.
* LDRIVE must be set (e.g. if your shell is BASH under LINUX, you''ll have
  to do a 'export LDRIVE=...' (set the appropriate value for '...', eg. '/dev/hda1')
  
Usage under UNIX is as described in section 1 and the online help, respectively,
with the following differences:
* Under UNIX the binaries do *NOT* have the '.exe' or '.bat' filename extension.
* ldir -part does not work under UNIX.				  
* In the documentation substitute the term 'DOS' by the name of your UNIX operating
  system.
  
  

6. History

The first version lread10 was written by Jason Hunter and David Lutz at 
Willamette University, Salem, Oregon, USA as a project in an Operating System
Class. I've included their original README.TXT file in the appendix. 
Good work, guys!

I found lread10.zip on Sunsite's server together with another program with
a similar functionality (exttools). When I tried them, the programs in
package exttools did work quite well, but they need gcc for compilation,  
resulting in 32bit programs running with a DOS extender. They are definitely 
not suited for being easily modified into a Windows NT program.

When I tried ldir/lread, it did not work at all, because my Linux is located
on DOS extended partitions, but version 1.0 did only detect primary parti-
tions. So I started to rewrite the harddisk detection code. When it finally
worked, I found out, that it could not handle big directories, so I rewrote
the buffering scheme and memory allocation code, when reading inodes, buil-
ding and listing directories. Finally I rewrote the user interface, added 
some command line options, much of the error handling code and 'styled' the
code to compile under Borland C, D.J.Delories gcc port and Linux gcc with-
out warnings...

Maybe it is of some use for you. If not, you can at least take my part of
the code as an example of bad programming practice or simply do a 
'mv lread/* /dev/null'  :-)) !



7. Acknowledgments
Thanks to Jason Hunter and Dave Lutz, who not only developped version 1.0 of
lread/ldir but also had a look into my modifications and suggested further
improvements.
Thanks also to all the guys, who provided information about various aspects
on harddisks and reported bugs. Some of them, whose findings led to code
improvements, are listed in the history section of main.c

Enjoy

Werner Zimmermann
FHTE, FB IT
Fachhochschule fuer Technik Esslingen, Germany
1 April 1999


############################################################################
Appendix: The original README.TXT of lread10:

Welcome to lread/ldir!

This program was written for an Operating Systems class at Willamette
University in Salem, Oregon, USA.  It is a DOS program (though it has
been shown to work under Linux) which reads the Linux ext2 filesystem.


USAGE

The usage is as follows:

ldir /any/Linux/path
	  and
lread /any/Linux/path[/filename] [savefile]

where bracketed items are optional.

Ldir will printout something akin to a "ls -l" for the given directory.  It
always outputs to stdout.  Lread will print actual files.  It will print to
stdout unless a savefile is given in which case it will save that file on
the DOS filesystem.  If lread is given a directory name instead of a file
name, it will display or save a dump of the directory.  We consider the
capability to both "dir" and "read" a directory a feature.


LDIR/LREAD DIFFERENCES

As you can tell by viewing the code, the only difference between ldir and
lread is the filename.  The program does a quick check of argv[0] and reacts
based on the name of the called program.  Under Linux you can simply link
ldir to lread, but under DOS you must make a full copy of the file.  So 
compile the code to be either lread or ldir and copy the other.


COMPILING TIPS

When you compile the code under DOS be sure to use the Compact memory model
or larger.  64K of data space is not enough for parsing large directories. 
Super-large directories still cause problems under DOS.


PROGRAM OPERATION

The program works by first reading the data about the hard drive in the
partition table.  It finds the first Linux partition on the first hard drive
(if you have more than one, change the code... we're graduating and done
with this at least for a while!).  It uses the drive specifications it finds
in the table to enable DOS to use BIOS calls to read outside the DOS
partition.

Using this capability, the program finds the inode of the first parameter
(kind of like performing a mini "stat" under DOS).  It chases down the path
piece by piece to find the inode of the last part.  It begins at the rood
directory (inode 2), loads that directory, and then scans it for the inode
corresponding to the next piece of the path.  It stops when it has resolved
the full path or hits a softlink or filename in the middle of the path.  (If
you care to allow it to follow softlinks, be my guest.  Please see my email
address below as a contact point.)

With this inode the program can follow the file block by block--through the
single indirect, double indirect, and triple indirect pointers.  After
reading each block it either displays it or writes it to a file.

When everything has finished the program reports any errors encountered or
the fact that no errors were found.  On ldir it only reports problems.

There is a list of problems and things to work on in main.c.  If you have
skills and interest, feel free to tackle some code modifications.  For at
least the near future work is keeping me too busy to continue working on
this.  Please report bugs and comments to the addresses below.


THE GOOD-BYE

Keep in touch on email!

jhunter@willamette.edu
jhunter@engr.sgi.com
dlutz@willamette.edu

Jason and Dave
