Am 12.07.2012 14:30, schrieb Laszlo Nagy: > This is not a contradiction. Although the rename operation is atomic, > the whole "change status" process is not. It is because there are two > operations: #1 delete old status file and #2. rename the new status > file. And because there are two operations, there is still a race > condition. I see no contradiction here.
Sorry, but you are wrong. It's just one operation that boils down to "point name to a different inode". After the rename op the file name either points to a different inode or still to the old name in case of an error. The OS guarantees that all processes either see the first or second state (in other words: atomic). POSIX has no operation that actually deletes a file. It just has an unlink() syscall that removes an associated name from an inode. As soon as an inode has no names and is not references by a file descriptor, the file content and inode is removed by the operating system. rename() is more like a link() followed by an unlink() wrapped in a system wide global lock. > It is not entirely true. We are talking about two processes. One is > reading a file, another one is writting it. They can run at the same > time, so flushing disk cache forcedly won't help. You need to flush the data to disk as well as the metadata of the file and its directory in order to survive a system crash. The close() syscall already makes sure that all data is flushed into the IO layer of the operating system. With POSIX semantics the reading process will either see the full content before the rename op or the full content after the rename op. The writing process can replace the name (rename op) while the reading process reads the status file because its file descriptor still points to the old status file. Christian -- http://mail.python.org/mailman/listinfo/python-list
