We are now receiving FS102's in addition to the FS107 we were getting before. This is happening on data tables and index tables. The index file is only 10k lv, 10k ov and is definately not read-only as reported. This time it even continued after the server and client were both reset. Out batch PC is the only machine accessing the server during this time so there will be no conflicts with anything else, especially after the server bounce.

Our revparam looks like this:

ServerOnly=1

ServerName=172.20.1.66

TcpIpPort=54321

and is in all directories containing rev files and the parent as well. Permissions shouldn't come into this as it works most of the time including this index table.

Additionally we had an FS1009 on a table that was already open last night; that was before the server reboot though.

Our server is a dual core xeon with hyperthreading. Could hyperthreading cause any issues? Something to rule out (or in)

These messages are appearing in your Arev 3.12 application, correct?

Do the FS102 and 107 messages appear in the server's event log from the LinearHash service?

What were your results checking the Open Files list or using the Sysinternal Handle Utility?

If you haven't used the handle utility yet please try running the command "openfiles /local ON" and reboot the server. Then download and run the handle utility from http://technet.microsoft.com/en-us/sysinternals/bb896655

When the problem occurs again run "handle.exe" from a command prompt on the server and check which process has the .LK/.OV file open.

Arev 3.12 and on the server in the event log generated by the linearhash service.

I've tracked open files and not found anything before now.

I have access to the server now so can diagnose a bit myself rather than rely on others and am using filemon to look for lk and ov access by anything other than UD.

I've had another read failure with sysinternals filemon logging any accesses to .lk or .ov by anything other than the UD service and nothing has shown up. I ran the handles utility and again the only lk or ov in use was by lh46srvc.exe.

Please help

When you say "FileMon" you mean Process Monitor, right?

Try and create a false positive when the monitor is running. First, on the server try opening a .LK file in notepad. Second, on a workstation, try opening a .LK file from a mapped network drive. The reason for doing this twice is because files accessed from the network occur under a system service account which doesn't always appear as a local program.

Thought I'd give an update on this:

We finally tracked this down to a user who have windows search indexer running and scanning network drives including our live data volume. We were getting buffer overflows and file lock refusals every time his indexer coincided with the arev indexer. Depending who got hold of the file first decided if we got UD service throwing read and write errors.

I know that we shouldn't have this situation but I really would have hoped UD to be much more graceful in the way it handled the situation. Perhaps if we ever get server based indexing it will be.

Thanks anyway for the help

View this thread on the Works forum...