But really, the basic idea is simple: renameat mishandles the case where old and 
new names are already hard links, and any code based on renameat needs to work 
around this problem. (We can't easily change renameat's behavior, as the 
behavior is required by POSIX.)
It isn't that simple, since renameat is a no-op if the source and destination 
are already hard links. So the patch you sent in would not work.
Dear Sir,
I might have then misinterpreted following paragraph fromman renameat(2) man page:
DESCRIPTION
       rename()  renames  a  file,  moving it between directories if required.  Any other hard
       links to the file (as created using link(2)) are unaffected.  Open file descriptors for
       oldpath are also unaffected.

       If newpath already exists, it will be atomically replaced (subject to a few conditions;
       see ERRORS below), so that there is no point at which  another  process  attempting  to
       access newpath will find it missing.

       If  oldpath  and  newpath  are  existing  hard  links  referring to the same file, then
       rename() does nothing, and returns a success status.

In my test code, renamat (AT_CWDFD, oldpath, AT_CWDFD, newpath, flags); successfully renames directory entry, yet inode number name in dir refers to is unchanged.
Do you think our development team could write a paper on this issue? Then I could justify drawing a schematic diagram?Is it trivial or is there some justified reason to publish and explain in detail?
Thank you very much.
Regards,
M.T.
 

    On Thursday, January 5, 2017 8:57 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
 

 Mirsad Goran Todorovac wrote:
> Please consider the trace below.

As I don't know what you're tracing, I don't know what to consider.

But really, the basic idea is simple: renameat mishandles the case where old and 
new names are already hard links, and any code based on renameat needs to work 
around this problem. (We can't easily change renameat's behavior, as the 
behavior is required by POSIX.)