MGI 1.x Known Conflicts
Notices of Known Conflicts or Limitations are listed in alphabetical
order of the product involved. Generally, the order is based on the manufacturer
of the product in question.
Adobe PageMill 2.0 and File Sharing
It has been noticed that the frequency of crashes involving a server
running WebStar and MGI APPEARS to increase when a volume from that server
is remotely mounted on another machine and one is using Adobe PageMill 2.0.
The crash takes place during a Save operation only and does not seem to
be related to merely mounting the drive or opening files remotely.
Given the other products running on a server along with so many other
variables associated with the system software and the local machine, it
is unknown if MGI contributes to the issue. It is worth to note that such
crashes occur on other machines not running MGI, though not enough statistical
information has been gathered to determine is there is an actual increase
in crashing between a server and a non-server machine. What seems to be
an increase may be simply due to the fact that we spend far more time sharing
volumes with server machines than we do with non-server machines.
The problems associated with Adobe PageMill 2.0 when it is used to alter
files over file sharing was discussed extensively on the PageMill talklist
hosted by BlueWorld, though no apparent resolution of the problem was decided
upon. Adobe PageMill 3.0 appears to correct the problem according to independent
reports, but that product has not been tested in our environment.
Clearway's Firesite
Some of the functions in MGI will not perform properly when Clearway's
Firesite is installed and configured as a WebStar preprocessor. Firesite,
when taking in a page for preprocessing, then handing it back to WebStar
for additional processing (by MGI or any other processing product,) changes
the IP number of the request to that of the server itself. Since MGI counters
and mgiIfClient are in some form dependent on the IP number of the incoming
request, those functions cease to work. Counters have a work around for
the problem as one of its optional parameters, but mgiIfClient does not.
Additionally, some cookie-related or isolated database functions that are
dependent on the incoming IP number of the request may be affected, though
we have eliminated all known issues.
Clearway's Nitro Power Plug
It is strongly recommended that any web server running WebStar use Nitro
Power Plug from Clearway Technology if you are using a version of WebStar
below 4.0. Nitro smooths out many memory management problems associated
with WebStar and the operating system. However, not all users of MGI can
use any of the three different flavors of Nitro. From our experience, Nitro
Regular will crash the server almost immediately. Nitro Super will run for
a time, then the server will crash. Nitro Ultra appears to give the maximum
benefit without affecting server operations. That may be a result of our
own system configurations involving other products and processes, though,
and be an effect independent of MGI. Then again, certain of our machines
do well with Regular and crash while using Ultra. Basically, find the one
that works for you and stick with it.
As instructed in the documentation for Nitro, it is suggested that you
start out with Ultra, then move to Super or Regular as needed according
to the performance of your own specific system configuration. There have
been no noticeable performance issues with WebStar and MGI running in concert
even without a variant of Nitro loaded on the system.
Nitro Power Plug is available at http://www.clearway.com
Folders Names and Tildes (~)
MGI keeps end-users from reading the content of files outside of their
root folder (e.g., domain) by reading files only to the root level of a
user's folder or to the first folder name containing a tilde (~). Some particular
files that MGI often needs to read are the database files in the MGI Data
folder (such as the counter, shopping basket, banner ad, variable and authentication
databases). The MGI Data folder is created at the root level of a user's
folder unless the tag that creates the database (i.e. mgiCounter, mgiShoppingBasket,
mgiBannerAd, mgiSet, and mgiAuthenticateDB) is located within a folder containing
a tilde. Then the MGI Data folder is created at the root level of the folder
containing a tilde.
Therefore, if a tag that creates a database is located below a folder
containing a tilde, then an MGI Data folder will be created at the root
level of the folder containing the tilde.
FTP Processes in general
When a user uploads a new file or folder from their local machine to
the server, the old folders or files are overwritten if they are named the
same as the new ones. At one time or another, most users of FTP have been
made painfully aware of that fact when they accidentally overwrite an entire
folder on the server only to find that all the old files are now gone. Most
people only do it once.
MGI creates a particular situation involving overwriting files that you
need to be made aware of. Anytime MGI is invoked to perform a database function
-- including mgiCounter -- a folder called MGI Data is created within the
web space of a client. Usually, that folder is found at the root level of
the domain, but it can be created in any folder where an mgiEditDatabase
tag is being used. The MGI Data folder is the repository of all database
information for that client and is unique to that client; for those ISPs
serving multiple domains on a single machine, each user has their own MGI
Data folder or folders as the case may be.
When using FTP, if a user is in the practice of altering pages locally,
then uploading the entire web site or specific folders to the server, they
will not have the MGI Database folder on their local machine. The upload
will overwrite the existing folder and wipe out the MGI Database folder
located on the server. Or similarly, if the user has an old copy of the
MGI Database folder on their local machine and does a wholesale FTP session
of a folder which contain the MGI Data folder, they will overwrite newer
information with old information.
Currently, there is no work around to that issue. Some FTP servers will
not allow older data to overwrite newer data, but none of them will prevent
a folder from completely replacing another folder. PagePlanet Software,
Inc. intends to create an FTP server that will eliminate that problem. It
will act as a normal FTP server, but will allow for administrative exclusions
on files and folders of specific names so that an FTP session will not be
able to accidentally remove them from the server. That project will not
begin until at least mid-summer 2001 at the earliest.
In the meantime, it is wise to instruct your users on the pitfalls of
FTP. It is also wise for ISPs to periodically back-up their user's files,
though ultimately the integrity of all user data rests squarely on the individual
user.
One thing that the user can do is to periodically make a back-up of the
MGI Data folder itself and keep it located in a safe place. Another thing
a user should do is to periodically export existing database tables to a
tab-delimited file and download that created file to their local machine.
That way, if the MGI Data folder is accidentally erased in an FTP session,
it can be reconstructed by re-creating the table and importing the data.
Instruct your users to also note the names and order of the fields in their
database tables so that it can be reconstructed according to the field ordering
as found in their tab-delimited file they exported as a back-up.
Starnine's WebStar -- Realms
MGI keeps end-users from reading the content of files outside of their
root folder (e.g., domain) by reading files only to the root level of a
user's folder or to the first folder name containing a tilde (~). Some particular
files that MGI often needs to read are the database files in the MGI Data
folder (such as the counter, shopping basket, banner ad, variable and authentication
databases). The MGI Data folder is created at the root level of a user's
folder unless the tag that creates the database (i.e. mgiCounter, mgiShoppingBasket,
mgiBannerAd, mgiSet, and mgiAuthenticateDB) is located within a folder containing
a tilde. Then the MGI Data folder is created at the root level of the folder
containing a tilde.
If you have created realms in WebStar, then MGI tags that need to access
the MGI Data folder outside of the realm cannot retrieve and display the
information because it is passcode protected. To use MGI tags at or below
a realm folder, simply include a tilde (~) somewhere in the name of the
realm folder (usually before, e.g., ~folder); the realm security is maintained
and an MGI Data folder is created at the root level of the realm folder.
White Pine's FTPShare
When a server running WebStar, MGI, and FTPShare by White Pine crashes,
there is a slight tendency for the target folder information within FTPShare
to be erased, forcing the administrator to re-connect the target folders
for each user. This seams to be a bug in FTPShare and not specifically related
to MGI, though when a server running MGI crashes, there may be some factor
of file system interaction associated with MGI that is contributing to the
problem.
White Pine no longer supports development nor provides technical support
for FTPShare, so we are unable to determine exactly what is the cause of
the problem or determine a solution. The situation appears to occur every
ten to fifteen crashes and seems to have no other affect. Once the target
folders in FTPShare are reconnected, FTPShare behaves normally. This appears
to be more of a phenomenal irritant that anything else.
|