Comment 1 for bug 1597429

I can confirm this behavior.

It seems to happen only on process with replication port. The process stop working after logging this error.

My theory: a reconstructor is moving/reconstructing a fragment. In the mean time, an other process (auditor, object server, ...) think the fragment is invalid because it has no durable file yet. As it's not a fresh object (timestamp < reclaim_age), the object is cleaned before the durable file has been written.

Checking mtime before cleaning reduce a lot the frequency of errors but there is other race condition i didn't figure out.