                     LTOOLS (formerly LREAD)  5.2
Program 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
                  (Email: Werner.Zimmermann@fht-esslingen.de)
                  (Web:   http://www.it.fht-esslingen.de/~zimmerma)

	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.

The newest version of the LTOOLS can be found under
	http://www.it.fht-esslingen.de/~zimmerma/software/ltools.htm

Contents:
        1. LTOOLS command line tools
        2. Using your web browser as a graphical user interface LREADsrv
        3. Using a Java program as a grapical user interface LTOOLgui
        4. Configuring and compiling LTOOLS
	5. Known Problems and To Do list, help wanted
        6. Running LTOOLS under UNIX and QDOS
	7. History
	8. Acknowledgements
	Appendix: lread10's original README.TXT

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

1. LTOOLS command line tools

If you want to run the LTOOLS under DOS/Windows, you'll find all
binaries and all support files in subdirectory ./bin.

If you want to run the LTOOLS tools under a UNIX operating system, binaries
and support files are under ./bin.unx; but please read this section *and*
section 6 first.

The package comes with executables ready to run under DOS/Windows(Windows 3.1,
95, 98, Windows NT):
	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 or (empty) directories
	lchange.bat   change Linux file attributes and owner
	lren.bat      rename Linux file
	lmkdir.bat    create a new Linux directory
	lln.bat	      create a symbolic link
	lcd.bat	      set the default Linux toplevel directory
	ldrive.bat    set the default Linux disk drive

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.

If you prefer using your web browser as a graphical user interface for the
LTOOLS, you may run
 	lreadsrv.exe
which provides a HTTP/HTML interface for your web browser. Details are described
in section 2.

If you have Java installed, you may use a Java program (stand alone application,
no applet), as a graphical user interface:
	lreadgui.bat	invokes the graphical user interface in ...
	lreadgui.jar	... Java archive for the GUI classes
Details are described in section 3.

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

The LTOOLS command line tools 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/...'.
	  You can also set the default drive by using the batch file
	  		ldrive /dev/hd...


  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.

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. When you call
lwrite, lwrite works as expected, but your floppy drive will start to spin (the
floppys contents will not be changed). This strange behaviour is not yet
solved.

The syntax is

ldel [-h | -v | -?] [-s/dev/hd..] Linux_File
	      Delete the specified file or (empty) directory or symbolic link!

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 be 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

lren [-h | -v | -?] [-s/dev/hd..] [-fFMODE] [-uUID] [-gGID] Linux_File_old_name Linux_File_new_name
	      Rename a Linux file, directory or symbolic link!
	      -u, -f, -g see above

lmkdir [-h | -v | -?] [-s/dev/hd..] [-fFMODE] [-uUID] [-gGID] new_Linux_directory
	      Create new Linux directory
	      -u, -f, -g see above

lln [-h | -v | -? ] [-s/dev/hd..] [-fFMODE] [-uUID] [-gGID] LinuxLinkTarget  LinuxLinkSource
	      Create new Linux symbolic link
	      -u, -f, -g see above

Wildcards are not yet supported for lwrite, ldel, lren and lchange.

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

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

2. Using your web browser as a 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 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. Using a Java program as a grapical user interface LTOOLgui

Starting with version 4.5 the Java program LTOOLgui is provided as a graphical user
interface. LTOOLgui consists of a batch file (LTOOLgui.bat for DOS/Windows and
LTOOLgui.sh for UNIX), the class files are in the archive LTOOLgui.jar (you do not
need to unarchive these files). Help is in some HTML-files ltoolguiX.htm (X=1,2,...).
Some icons for ltoolgui are in subdirectory bin/images.To invoke the GUI, simply type
		ltoolgui
(DOS/Windows binaries are in the .\bin, UNIX binaries are in the ./bin.unx
subdirectories).
To run ltoolgui, you need the Java Runtime environment version 1.2.x or newer. The Java
runtime environment must be properly installed with the appropriate path and classpath
variables set.

LTOOLgui runs as a standalone application, not as an applet. The LTOOLS command line
tools must be in the same directory as ltoolgui. You also should set environment
variable LDRIVE (see section 1).

For more information, please have a look into the LTOOLgui's online help.

LTOOLgui is based on Java Swing, as it is included in JDK 1.2. If you do not have
JDK 1.2.x or newer, use the AWT version LREADgui, which is already included in the
package since version 3.4. LTOOLgui definitely does not work with Microsoft Java!

If you want to have remote access to your LINUX files, run LREADjav.exe. LREADjav
allows a LTOOLgui or LREADgui client to connect from a remote host. When you start LREADjav,
you may specify the servers portnumber (default is 1605) and up to 3 IP addresses.
Only clients from these IP addresses may connect to LREADjav. To access a remote
host, use LTOOLgui or LREADgui's menu item 'Remote connect'.

To compile LTOOLgui, edit the makefile (makefile.unx for UNIX) in directory .\java\swing.
Then compile by			make
To compile LREADLgui, edit the makefile (makefile.unx for UNIX) in directory .\java\awt.
Then compile by			make
To compile LREADgui, edit the makefile (makefile.unx when using UNIX) in directory .\java.
Then compile by			make
Binaries will be in directory .\bin (or ./bin.unx).


Note: 	From a user's perspective, LTOOLgui/LREADjav  and LREADsrv/webbrowser are
	functionally (nearly) identical. When you are working locally, you may
	prefer LTOOLgui and LREADjav is not needed. If you want to use your web
	browser as GUI, you must have LREADsrv running, even if you are only
        working locally. Nevertheless, on slow machines (with respect to Java
        a Pentium 200MHz is slow!) LREADgui may not be the best choice, be-
        cause longer directory listings cause the screen to flicker heavyly.
        Unfortunately, I have not yet found a means against this (double
        buffering and all the usual tricks did not work noticably better).

If you need to do troubleshooting in LTOOLgui, edit the file LTOOLgui.java
and set "static final boolean DEBUG = true" (its near the beginning of the
file) and recompile. This will enable debug messages printed to the console
window.

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

4. Configuring and Compiling the LTOOLS

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 the Windows NT/2000 case, you
may also use Microsoft Visual C++. See the makefile for details.

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.

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

5. Known Problems and To Do List, Help Wanted

Big Harddisks (harddisks with more than 1024 cylinders, i.e. > 8GB)
Under Windows NT disks are addressed with a 64bit sector value and even very big
disks should not be a problem for the LTOOLS.
Under Windows 95/98 a 64bit access is simulated, if Windows does support
BIOS extensions for harddisk access. This should work in any case in Window's DOS
box. If you work under plain DOS, this might or might not work depending on your
PC vendor's BIOS. Even new BIOS seem to have problems with big harddisks.

Big Harddisk Partitions when using the LTOOLS under Linux/Unix
If you use the LTOOLS under Linux, disk size is not a problem, but partition size is!
With respect to the LTOOLS no single Linux partition may be bigger than 4GB!
The reason is, that under Linux the LTOOLS treat a disk partition as a normal file
and address it by a 32bit offset via a normal operating system file read/write.
However, with 32bits you can only address 4GB ... This is not a LTOOLS problem but
a problem of the underlying Linux system function. Windows does not have this problem!


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, run 'ldir -part >list1'. This list you partition table in file 'list1'.
Look, what the LTOOLS think about your harddisk. If you think, you've got
a problem, mail me this file 'list1' together with a description of your
setup.

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 ...).

Note: Since version V4.5 debugging can be initiated without recompiling via
command line switch '-deb=X', where X is a value between 0 and 63. X is the
or'ed value of the DEBUG_... defines defined in file ldir.h.


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

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

6. Running LTOOLS under UNIX and QDOS

In subdirectory ./bin.unx you'll find binaries for running the LTOOLS
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, LTOOLS 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, LTOOLS
(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 LTOOLS 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.

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

7. 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'  :-)) !

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

8. 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
FH Esslingen - Hochschule fuer Technik
University of Applied Sciences
Esslingen, Germany
08 Feb. 2000


############################################################################
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
