[sword-devel] new logic in filemgr and module drivers

[Troy A. Griffitts]

For some time now, I've been wanting to change the way filemgr and
module drivers work in this regard:

	It used to be that when constructing a driver, by default the driver
would try to get write access to its files.  If it could not get write
access, it would 'downgrade' to read-only.

	There are a few problems with this...

	This logic was done repeatedly in each driver constructor.  It has now
migrated to FileMgr.  There is a new parameter on FileMgr::open, bool
tryDowngrade which defaults to false.  If you are asking to open a file
with O_RDWR and pass true for this parameter, the FileMgr will first try
to obtain read/write access on the file; failing that, it will attempt
read access on the file.  If you pass false for tryDowngrade (the
default), the open will fail as before if you ask for write access and
cannot get write access.

	The next problem having this checking logic in the constructors of each
driver was that it forced the FileMgr (that delays opening files until
needed) to actually open each file when checking if write access was
obtainable.  This logic has been moved to the delayed open call.  This
is significant when creating a new SWMgr.  SWMgr construction does not
require opening each file used by each driver any longer.  We should see
some good speed improvements-- especially in applications like
InstallMgr that construct SWMgr objects over and over and sometimes from
a CDROM that has much slower file access.

	Finally, most of the SWModule subsclasses' isWritable() methods will
report correctly if the user actually has write access to the file;  not
merely if the driver is capable of write operations.


	Having said all this.  These changes constitute (most likely) the last
significant change before 1.5.3.  Please see if current cvs works for
all of your applications and let us know!

		Thanks so much.  We'll get this thing wrapped up soon, Lord willing!

			-Troy.