On success, OK to leave .bak file as rename() will break the link so that krb5.conf has a link count of 1.

If do nothing upon rename() failure, krb5.conf will end up with a link count of 2.

We Oracle has modified the open() of krb5.conf with a bunch options including O_NOLINKS.
If rename() failed and link count of krb5.conf is > 1, open() of krb5.conf fails with EMLINK (The O_NOLINKS flag is set and the named file has a link count greater than 1).

The .bak is removed right before the make_hard_link().  So if the new krb5.conf can not be kept because combined make_hard_link() & rename() have failed, seems clean not to keep the extra "linked" .bak around. 

Thanks.
Tsu-Phong

----- Original Message -----
From: rt-comment@krbdev.mit.edu
To: tsu-phong.wu@oracle.com
Sent: Thursday, September 25, 2014 10:14:52 AM GMT -08:00 US/Canada Pacific
Subject: [krbdev.mit.edu #8020] rename() failure in src/util/profile/prof_file.c:write_data_to_file()

It looks like the intent of this code is to leave behind the .bak file 
(old_file) on success.  So why is it necessary to remove it on rename 
failure?

Also, are you seeing undesirable behavior in practice?  If so, under what 
circumstances?