[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25342: GNU coreutils: race condition in "ln -f source dest"
From: |
Mirsad Goran Todorovac |
Subject: |
bug#25342: GNU coreutils: race condition in "ln -f source dest" |
Date: |
Sun, 8 Jan 2017 00:26:19 +0000 (UTC) |
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 <address@hidden> 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.)
- bug#25342: GNU coreutils: race condition in "ln -f source dest", Mirsad Goran Todorovac, 2017/01/02
- bug#25342: GNU coreutils: race condition in "ln -f source dest", Paul Eggert, 2017/01/02
- bug#25342: GNU coreutils: race condition in "ln -f source dest", Mirsad Goran Todorovac, 2017/01/02
- bug#25342: GNU coreutils: race condition in "ln -f source dest", Paul Eggert, 2017/01/03
- bug#25342: GNU coreutils: race condition in "ln -f source dest", Mirsad Goran Todorovac, 2017/01/04
- bug#25342: GNU coreutils: race condition in "ln -f source dest", Paul Eggert, 2017/01/05
- bug#25342: GNU coreutils: race condition in "ln -f source dest", Mirsad Goran Todorovac, 2017/01/05
- bug#25342: GNU coreutils: race condition in "ln -f source dest", Mirsad Goran Todorovac, 2017/01/05
- bug#25342: GNU coreutils: race condition in "ln -f source dest", Mirsad Goran Todorovac, 2017/01/05
- bug#25342: GNU coreutils: race condition in "ln -f source dest",
Mirsad Goran Todorovac <=
- bug#25342: GNU coreutils: race condition in "ln -f source dest", Paul Eggert, 2017/01/07