race condition between 2 namenodes in standby that are trying to checkpoint with one another can delete or corrupt a good fsimage

The problem occurs under concurrent execution of the namenode running its own checkpoint in StandbyCheckpointer in thread 1 while also getting a checkpoint from a different namenode in GetImageServlet in thread 2. It is possible for thread 2 to finish writing the checkpoint to the directory, but then get suspended before it has a chance to rename it to its final destination as an fsimage file. Then, thread 1 wakes up and starts writing its own data to the checkpoint file. When thread 2 resumes, it then tries to rename the file that thread 1 still holds open for writing. Depending on OS, this either moves thread 1's incomplete checkpoint to fsimage, or it just outright deletes the existing good fsimage until thread 1 finishes writing and renames.