LTOOLS (formerly LREAD) 5.6 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, 2000, XP): 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, 2000, XP: ldirNT.exe This file is not called directly by the user but is called indirectly via ldir.exe, when ldir.exe detects Windows NT, 2000, XP. In order to read the harddisk under Windows NT/2000/XP 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. LTOOLGUI can also be run as an applet in a web browser. For details see file "ltoolapplet.htm". ------------------------------------------------------------------------------- 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/2000/XP, 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/XP 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/2000/XP 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: or 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/2000/XP 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 first 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, Department of Information Technology FH Esslingen - University of Applied Sciences Esslingen, Germany 01 March 2002 ############################################################################ 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