As mentioned, because Insight uses a file-based database, we must trust the filesystem to be reliable. The Insight database has built-in transactional controls to prevent data corruption in standard power-loss or drive disconnection situations, but it cannot protect against a filesystem that claims to do one thing while doing another.

All sharing relies on the network filesystem correctly implementing standard file locking protocols. These are used to ensure that only one user at a time is modifying a given part of the file, and that after modification, all users see the updated and consistent version of the data. If a network filesystem claims to issue a lock over a piece of data, but does not actually prevent concurrent access, then the database file will very quickly become corrupted.

Because Insight uses filesystem locking functions that are entirely standard, this is not usually something that you need to be specifically concerned about. However, it is best (and not difficult) to verify, especially where multiple network filesystem technologies are used.

For example, a typical configuration in an environment with both Linux and Windows users is to provide filesystem access via NFS to Linux and via CIFS/Samba to Windows. It is vital that these two systems coordinate file locking in such a way that a lock taken via NFS is also enforced against CIFS/Samba users (and vice-versa). This situation is the most likely opportunity for corruption.


IMPORTANT NOTE: Machines running Linux and many network attached storage [NAS] devices use Samba for sharing files. In a multi-user Insight environment, it is critical that Opportunistic Locks are disabled for the project directories to avoid database corruption. For details on opportunistic locks and their implications, please see this page on the Samba website.


To make it as easy as possible for administrators to validate their filesystem environments, Insight 4 includes a built-in filesystem testing tool. This tool generates database traffic that is designed to induce and detect corruption as quickly as possible in the absence of proper locking.

It is important to run this test on at least two machines at once, as it is only through concurrent access that such problems will be found. You will want to run this tool in such a way that all filesystem paths are tested simultaneously. For example, if you have Linux, Windows, and Mac OS X systems, and multiple paths by which a single filesystem can be mounted, you must test all such paths at the same time.

To run the testing tool:

  1. Install and run the Insight launcher as usual.
  2. To avoid the potential for damage to an existing project, create a new project just for this test. All systems involved in the test should open this same project.
  3. Launch the main Insight program.
  4. From the Help menu, click on Debug and choose Database Test Tool.
  5. Click Start.

Repeat on each machine involved in the test. If there is a filesystem locking problem, it is likely that the test will almost immediately fail. However, we recommend letting it run for a period of hours (e.g. overnight) to be certain, particularly if there are many different interlocking systems involved.

If the test fails, please contact [email protected] to discuss how best to proceed.