On Thu, Aug 23, 2018 at 02:50:31PM -0500, Derek Martin wrote: > Alternatively, if you're convinced that the link() success status is > reliable, you can do the stat comparison conditionally, only if it > returns failure. Again, the reason to do this is to determine if the > link actually succeeded, but brokenly reported failure due to NFS > quirks.
I've been thinking, researching, and rereading the thread. Everywhere I can actually find a concrete description of the problem with link()'s return value, the explanation has been a failure code that was in fact a success (because of NFS). So, I'm convinced trusting a 0 return value is acceptable, and am going to keep the current committed behavior for that case. I'm not too excited about changing the -1 return value case, because no issues have been reported in the 20-year old function related to that. But I admit it's documented, both historically and in the man page, and so it deserves handling. Your sample code and the man page for rename() also both mention the problem of leaving the oldpath if it is a hard link to newpath. So, I will attempt and post a patch for that fix in a new thread. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
