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.)