We are regularly encountering a problem where records become corrupted. I would appreciate any suggestions on finding the root cause. Here are the symptoms:

* Data within a record seems to have been swapped with that of a Windows application. Sometimes it is the contents of a DLL. Most recently, it consisted of a portion of a web site from the intranet.

* There is NEVER a GFE encountered at the same time. I mention this because it seems to me that if the corruption were to occur while writing frames, then at least occasionally a GFE would appear, since the corruption would also include frame information.

* There is an MFS on the file. The MFS logs all changes to the record at the time of the change. This MFS never detects the corruption. In other words, when the corruption occurs, it does not get logged. We only find out after the fact that there has been some corruption. This tells me that the record was intact when forwarded on to the MFS and became corrupted in transit between the BFS call and the physical write somewhere.

Very few of our users are using Client32. I have pushed for implementation of client32 as a default configuration for Arev users, but infrastructure changes have made this difficult.

Any suggestions or ideas about root cause and/or possible resolutions are appreciated.

Only thing I can think of off the top of my head is a file handle corruption problem.

Can you modify the MFS to re-read after a write for verification? Will be slower, yes, but at least you can find it.

[email protected]

Sprezzatura Group

Rereading after writing is a definite possibility. Don't know why I didn't think of that. It would certainly catch the problem at the earliest opportunity (assuming it does catch the problem).

I'm not certain the problem happens on writes, though. The reason I say this is that I have already implemented a process that works like this:

Suppose the main file is X. There is a backup file called X_OLD. When a write operation occurs on X, the MFS intercepts the call and checks for the existence of a record with the same key on X_OLD. If no record is found, the current record is written to X_OLD prior to posting to X. If the record already exists, it is left alone.

The interesting thing about this scenario is that the most recent time the corruption occurred, there was no record on X_OLD. The file X_OLD was cleared out last week upon verification that there were no corrupted records on file. This tells me the corruption is not the result of a write operation.

I recall having a similar problem when a Novell workstation had its printer set up as a shared printer via Microsoft Networking. Every time someone printed to this workstation while AREV was active, it would dump code fragments into the LH tables being written to.

View this thread on the forum...