Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Yes, glibc's rename() API guarantees atomic renames. Since normal applications do not make syscalls directly, but call the libc API to do it on their behalf, they are not to blame.
Glibc change exposing bugs
Posted Nov 11, 2010 8:46 UTC (Thu) by bojan (subscriber, #14302)
The atomicity of rename() refers to a view from the running system and not much else. But it has sure been misread a lot :-)
Posted Nov 11, 2010 9:06 UTC (Thu) by Mook (guest, #71173)
Posted Nov 11, 2010 9:52 UTC (Thu) by bojan (subscriber, #14302)
Posted Nov 11, 2010 13:49 UTC (Thu) by pbonzini (subscriber, #60935)
Posted Nov 11, 2010 23:05 UTC (Thu) by bojan (subscriber, #14302)
What glibc docs are talking about is that rename() is not implemented by copying content of the oldname to newname. So, if there was newname before rename and the directory commit doesn't go through, the content of newname will not be changed. It is a pure directory operation. On the other hand, if the directory gets committed, there will be just newname there, pointing to whatever content oldname had. All of that is if your FS knows how to survive a crash - otherwise situation is not interesting (well, unless you're the sysadmin recovering the mess :-).
Now note the situation from the ext4 "problem". The oldname content was not fsync()-ed to disk before the rename(). Ergo, when the directory got committed, oldname became newname on disk, pointing to zero bytes, due to delayed allocation. This has nothing to do with the fact that on unsuccessful (i.e. not committed before the crash) rename(), both oldname and newname would remain in the directory.
Posted Nov 12, 2010 7:12 UTC (Fri) by Mook (guest, #71173)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds