When majority read concern is off, we take unstable checkpoints ("use_timestamp=false") in the checkpoint thread. This prevents the checkpoint_timestamp entry from appearing in the WiredTiger.backup file to properly restore a WiredTiger backup taken via filesystem copies.

However, when the fsyncLock command is run, it takes a checkpoint after locking the instance. A checkpoint is taken with "use_timestamp=true", which is a stable checkpoint and includes the checkpoint_timestamp entry in the WiredTiger.backup file. This is not the desired behaviour and overwrites the correct setting chosen earlier by the checkpointing thread.

fsyncLock calls WiredTigerKVEngine::flushAllFiles with stableCheckpoint = true. When stableCheckpoint is true, we take a stable checkpoint. This needs to be changed to take an unstable checkpoint when majority read concern is off.

This problem went away in v4.2 and later versions from the work done in SERVER-37897.