Production post mortem: The opener of files and destroyer of peace

A customer opened a support call about a recurring problem that they had in their system.

System.InvalidOperationException: Errno: 1224='The requested operation cannot be performed on a file with a user-mapped section open. ' (rc=0) - 'Failed to rvn_write_header 'headers.one', reason : FailOpenFile'. FailCode=FailOpenFile. at Sparrow.Server.Platform.PalHelper.ThrowLastError(FailCodes rc, Int32 lastError, String msg) in C:BuildsRavenDB-Stable-4.242040srcSparrow.ServerPlatformPalHelper.cs:line 35 at Voron.StorageEnvironmentOptions.DirectoryStorageEnvironmentOptions.WriteHeader(String filename, FileHeader* header) in C:BuildsRavenDB-Stable-4.242040srcVoronStorageEnvironmentOptions.cs:line 706 at Voron.Impl.FileHeaders.HeaderAccessor.Modify(ModifyHeaderAction modifyAction) in C:BuildsRavenDB-Stable-4.242040srcVoronImplFileHeadersHeaderAccessor.cs:line 200 at Voron.Impl.Journal.WriteAheadJournal.JournalApplicator.SyncOperation.UpdateDatabaseStateAfterSync() in C:BuildsRavenDB-Stable-4.242040srcVoronImplJournalWriteAheadJournal.cs:line 998 at Voron.Impl.Journal.WriteAheadJournal.JournalApplicator.LockTaskResponsible.RunTaskIfNotAlreadyRan() in C:BuildsRavenDB-Stable-4.242040srcVoronImplJournalWriteAheadJournal.cs:line 1192 

And the code that failed was:

Based on that information, the issue is obvious. Someone is poking their nose into RavenDB’s files. It is important to understand that this will cause the I/O operation to fail. And since this is part of a critical path in managing the file, it will force the entire database to unload.

We asked the customer to make sure that all indexing services, anti virus programs and the like would be instructed to ignore the RavenDB directories and were assured that this is already the case.

That led us to a problem. If no one else is touching our files, is it possible that it is our own code that is causing the issue?