import 0.9.2.2

Makefile

@@ -10,14 +10,22 @@ kernelconf: patch
 compile: kernelconf
 	make -C src
 
-install: compile
+install:
+	make -C src
 	make -C src install
+	make -C man install
 	sh magic.sh
 
 uninstall:
 	make -C src uninstall
+	make -C man uninstall
 
 mrproper:
 	rm -f *~
 	rm -f doc/*~
+	rm -f man/*~
+	rm -f patches/*~
 	make -C src mrproper
+
+dist:
+	sh mkdist.sh

README

@@ -15,7 +15,14 @@ any more.
 List of files to read:
 ----------------------
 
-README          this file
-INSTALL.TXT     how to install CVF-FAT and dmsdos
-DIFFS.TXT       description of kernel patches ("when do I use which one")
-doc/*           various documentation
+README             this file
+INSTALL.TXT        how to install CVF-FAT and dmsdos
+patches/DIFFS.TXT  description of kernel patches ("when do I use which one")
+PORT_TO_WIN32      if you want to run dmsdos utilities in a Win32 environment
+
+Other directories:
+
+doc/            various documentation
+man/            man pages for dmsdos utilities
+src/            complete source code for dmsdos
+patches/        kernel patches and updates for the CVF-FAT interface

dmsdos.lsm

@@ -1,35 +1,39 @@
 Begin3
 Title:		dmsdos
-Version:	0.9.1.5
-Entered-date:	18AUG1998
+Version:	0.9.2.2
+Entered-date:	04DEC1999
 Description:	dmsdos: reads and writes compressed dos filesystems (CVF-FAT)
                 * read and write access to compressed partitions (files like 
                   dblspace.xxx, drvspace.xxx and stacvol.xxx). The following 
                   configurations are supported:
                        - DoubleSpace / DriveSpace (msdos 6.x)
-                       - DoubleSpace / DriveSpace (win95)
-                       - DriveSpace 3 (win95 with Plus! pack)
+                       - DoubleSpace / DriveSpace (older win95 releases)
+                       - DriveSpace 3 (win95 with Plus! pack or newer win95)
                        - Stacker 3
                        - Stacker 4
                 * Works with FAT32, NLS, codepages etc. (tested with fat32 
                   patches version 0.2.8 under Linux 2.0.33 and with fat32 in
-                  standard 2.1.xx kernels and 2.0.34+35) 
+                  standard 2.1.xx kernels and 2.0.[34-36], also tested with
+                  2.2.[0-2] kernels). Tested with patched 2.2.13 and 2.3.30.
                 * Dmsdos can run together with vfat or umsdos for long
                   filenames.
                 * Dmsdos has been redesigned to be ready for SMP.
-                * Dmsdos should now compile completely under libc6.
+                * Dmsdos compiles both under libc5 and libc6.
+                * The dmsdos library and some dmsdos tools compile even in a 
+                  32 bit Dos/Windows environment.
 Keywords:	filesystem compression doublespace drivespace stacker
 Author: 	[email protected] (Frank Gockel)
                 [email protected] (Pavel Pisa)
 Maintained-by:	[email protected] (Frank Gockel)
                 [email protected] (Pavel Pisa)
 Primary-site:	sunsite.unc.edu /pub/Linux/system/Filesystems/dosfs
-                230 kB dmsdos-0.9.1.5.tgz
+                262 kB dmsdos-0.9.2.1.tgz
 Alternate-site: ftp.uni-stuttgart.de /pub/systems/linux/local/system
-                230 kB dmsdos-0.9.1.5.tgz
+                262 kB dmsdos-0.9.2.1.tgz
                 fb9nt.uni-duisburg.de /pub/linux/dmsdos
-                230 kB dmsdosfs-0.9.1.5.tgz
+                262 kB dmsdosfs-0.9.2.1.tgz
 Original-site:
-Platforms:	Linux 2.0.xx (xx>=29), 2.1.yy (yy>=94), msdos 6.x, win95
+Platforms:	Linux 2.0.29 up to 2.0.36, 2.1.94+, 2.2.0+, 2.2.13+,
+                msdos 6.x, msdos 7.x, win95, winnt 4.0
 Copying-policy:	GPL
 End

doc/FAQ

@@ -203,3 +203,13 @@ under kernel 2.0.34. In that case, you may share one precompiled dmsdos
 module with several kernels. But please don't overuse it. You should not,
 for example, use the same compiled object code of a dmsdos module for
 kernel 2.0.34 and 2.1.105 - this is very likely to cause problems :)
+
+
+
+Where does the name "DMSDOS" come from ?
+
+It has historical reasons. The first piece of dmsdos code was written in 
+times of MSDos 6.2 when Doublespace became very popular. Thus, dmsdos was
+meant as something like "doublespaced msdos". Today, it supports a lot of 
+more compressed Dos filesystems, and a better name would be "cmsdos" for 
+"compressed msdos". But you never change the name of a successful project :)

doc/cvf-fat.doc

@@ -1,217 +1,4 @@
-cvf-fat.doc
 
-This is the main documentation for the CVF-FAT filesystem extension.  31DEC1997
-
-
-Table of Contents:
-
-1. The idea of CVF-FAT
-2. Restrictions
-3. Mount options
-4. Installation
-5. Description of the CVF-FAT interface
-6. Authors and email addresses
-
-------------------------------------------------------------------------------
-
-
-1. The idea of CVF-FAT
-------------------------------------------------------------------------------
-
-CVF-FAT is a FAT filesystem extension that provides a generic interface for
-Compressed Volume Files in FAT partitions. Popular CVF software, for
-example, are Microsoft's Doublespace/Drivespace and Stac's Stacker.
-Using the CVF-FAT interface, it is possible to load a module that handles
-all the low-level disk access that has to do with on-the-fly compression
-and decompression. All other part of FAT filesystem access is still handled
-by the FAT, MSDOS or VFAT or even UMSDOS driver.
-
-CVF access works by redirecting certain low-level routines from the FAT
-driver to a loadable, CVF-format specific module. This module must fake
-a normal FAT filesystem to the FAT driver while doing all the extra stuff
-like compression and decompression silently.
-
-
-2. Restrictions
-------------------------------------------------------------------------------
-
-- BMAP problems
-
-  CVF filesystems cannot do bmap. It's impossible by principle. Thus
-  all actions that require bmap do not work (swapping). Writable mmapping
-  should work via readpage, but is untested. Does anyone know an application
-  that is doing writable mmaps? This would be needed for tests :)
-
-- DOSEMU users attention 
-
-  You may have to unmount all CVF partitions before running DOSEMU depending 
-  on your configuration. If DOSEMU is configured to use wholedisk or 
-  partition access (this is often the case to let DOSEMU access 
-  compressed partitions) there's a risk of destroying your compressed 
-  partitions or crashing your system because of confused drivers.
-
-  Note that it is always safe to redirect the compressed partitions with 
-  lredir or emufs.sys. Refer to the DOSEMU documentation for details.
-
-
-3. Mount options
-------------------------------------------------------------------------------
-
-The CVF-FAT extension currently adds the following options to the FAT
-driver's standard options:
-
-  cvf_format=xxx
-    Forces the driver to use the CVF module "xxx" instead of auto-detection.
-    This is only necessary if the CVF format is not recognized correctly
-    because of bugs or incompatibilities in the CVF modules. (It skips
-    the detect_cvf call.) "xxx" may be the text "none" (without the quotes)
-    to inhibit using any of the loaded CVF modules, just in case a CVF
-    module insists on mounting plain FAT filesystems by misunderstanding :)
-
-  cvf_options=yyy
-    Option string passed to the CVF module. I.e. only the "yyy" is passed
-    (without the quotes). The documentation for each CVF module should 
-    explain it since it is interpreted only by the CVF module. Note that 
-    the string must not contain a comma (",") - this would lead to 
-    misinterpretation by the FAT driver, which would recognize the text 
-    after a comma as a FAT driver option and might get confused or print 
-    strange error messages. The documentation for the CVF module should 
-    offer a different seperation symbol, for example the dot ".", which
-    is only valid inside the string "yyy".
-
-
-4. Installation
-------------------------------------------------------------------------------
-
-Just apply the diff cvf.diff-x.y.z to your kernel. I hope the diff will
-make it into the standard kernel some day, but it's not up to me to decide
-this :) Note that the diff has been created using kernel x.y.z so it might
-fail or need manual interaction for other kernels. Modified diffs for
-other kernels welcome :)
-
-Well, you also need a CVF module to load. Otherwise CVF-FAT is quite useless
-to you :) dmsdos is such a module.
-
-
-5. Description of the CVF-FAT interface
-------------------------------------------------------------------------------
-
-Assuming you want to write your own CVF module, you need to write a lot of
-interface funtions. Most of them are covered in the kernel documentation
-you can find on the net, and thus won't be described here. They have been
-marked with "[...]" :-) Take a look at include/linux/fat_cvf.h.
-
-struct cvf_format
-{ int cvf_version;
-  char* cvf_version_text;
-  unsigned long int flags;
-  int (*detect_cvf) (struct super_block*sb);
-  int (*mount_cvf) (struct super_block*sb,char*options);
-  int (*unmount_cvf) (struct super_block*sb);
-  [...]
-  void (*cvf_zero_cluster) (struct inode*inode,int clusternr);
-}
-
-This structure defines the capabilities of a CVF module. It must be filled
-out completely by a CVF module. Consider it as a kind of form that is used
-to introduce the module to the FAT/CVF-FAT driver.
-
-It contains...
-  - cvf_version:
-      A version id which must be uniqe. Choose one.
-  - cvf_version_text:
-      A human readable version string that should be one short word 
-      describing the CVF format the module implements. This text is used
-      for the cvf_format option. This name must also be uniqe.
-  - flags:
-      Bit coded flags, currently only used for a readpage/mmap hack that 
-      provides both mmap and readpage functionality. If CVF_USE_READPAGE
-      is set, mmap is set to generic_file_mmap and readpage is caught
-      and redirected to the cvf_readpage function. If it is not set,
-      readpage is set to generic_readpage and mmap is caught and redirected
-      to cvf_mmap.
-  - detect_cvf:
-      A function that is called to decide whether the filesystem is a CVF of
-      the type the module supports. The detect_cvf function must return 0
-      for "NO, I DON'T KNOW THIS GARBAGE" or anything !=0 for "YES, THIS IS
-      THE KIND OF CVF I SUPPORT". The function must maintain the module
-      usage counters for safety, i.e. do MOD_INC_USE_COUNT at the beginning
-      and MOD_DEC_USE_COUNT at the end. The function *must not* assume that
-      successful recognition would lead to a call of the mount_cvf function
-      later. 
-  - mount_cvf:
-      A function that sets up some values or initializes something additional
-      to what has to be done when a CVF is mounted. This is called at the
-      end of fat_read_super and must return 0 on success. Definitely, this
-      function must increment the module usage counter by MOD_INC_USE_COUNT.
-      This mount_cvf function is also responsible for interpreting a CVF
-      module specific option string (the "yyy" from the FAT mount option
-      "cvf_options=yyy") which cannot contain a comma (use for example the
-      dot "." as option separator symbol).
-  - unmount_cvf:
-      A function that is called when the filesystem is unmounted. Most likely
-      it only frees up some memory and calls MOD_DEC_USE_COUNT. The return
-      value might be ignored (it currently is ignored).
-  - [...]:
-      All other interface functions are "caught" FAT driver functions, i.e.
-      are executed by the FAT driver *instead* of the original FAT driver
-      functions. NULL means use the original FAT driver functions.
-      If you really want "no action", write a function that does nothing and 
-      hang it in instead.
-      WARNING: Do not call a fat driver function from these routines without
-      looking at the fat driver source code first. You might end up in an
-      endless recursion. :(
-  - cvf_zero_cluster:
-      The cvf_zero_cluster function is called when the fat driver wants to
-      zero out a (new) cluster. This is important for directories (mkdir).
-      If it is NULL, the FAT driver defaults to overwriting the whole
-      cluster with zeros. Note that clusternr is absolute, not relative
-      to the provided inode.
-
-Notes:
-  1. The cvf_bmap function should be ignored. It really should never
-     get called from somewhere. I recommend redirecting it to a panic
-     or fatal error message so bugs show up immediately.
-  2. The cvf_writepage function is ignored. This is because the fat
-     driver doesn't support it. This might change in future. I recommend
-     setting it to NULL (i.e use default).
-
-int register_cvf_format(struct cvf_format*cvf_format);
-  If you have just set up a variable containing the above structure,
-  call this function to introduce your CVF format to the FAT/CVF-FAT
-  driver. This is usually done in init_module. Be sure to check the
-  return value. Zero means success, everything else causes a kernel
-  message printed in the syslog describing the error that occured.
-  Typical errors are:
-    - a module with the same version id is already registered or 
-    - too many CVF formats. Hack fs/fat/cvf.c if you need more.
-
-int unregister_cvf_format(struct cvf_format*cvf_format);
-  This is usually called in cleanup_module. Return value =0 means
-  success. An error only occurs if you try to unregister a CVF format
-  that has not been previously registered. The code uses the version id
-  to distinguish the modules, so be sure to keep it uniqe.
-
-Refer to the dmsdos module (the successor of the dmsdos filesystem) for a
-sample implementation.
-
-
-6. Authors and email addresses:
-------------------------------------------------------------------------------
-
-The CVF-FAT extensions are the official successor of the dmsdos filesystem.
-The dmsdos filesystem was initially written by Frank Gockel. Stacker support
-was added by Pavel Pisa. Meanwhile, it contains several parts of code that
-was directly provided or code that is based on the ideas from a lot of people
-over the net in order to fix bugs, to improve performance, and to add features.
-
-The code is distributed under the GNU General Public Licence (see file 
-COPYING).
-
-The code is currently maintained by Pavel Pisa and me, Frank Gockel.
-
-Pavel's email address is [email protected],
-my email address is [email protected].
-
-If you want to contact me via email, please write in English or take a close
-look at the country code in the email address :-)
+Documentation for the CVF-FAT interface is part of the Linux kernel
+(either directly in 2.1.xx or after applying the CVF-FAT patch for 2.0.xx).
+It can be found in file linux/Documentation/filesystems/fat_cvf.txt.