bug-coreutils
[Top][All Lists]
Advanced

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


   

reply via email to

[Prev in Thread] Current Thread [Next in Thread]