|
From: | Bob Friesenhahn |
Subject: | bug#12366: [gnu-prog-discuss] bug#12366: Writing unwritable files |
Date: | Thu, 6 Sep 2012 13:21:31 -0500 (CDT) |
User-agent: | Alpine 2.01 (GSO 1266 2009-07-14) |
On Thu, 6 Sep 2012, Paolo Bonzini wrote:
I'm not sure what is meant by "insecure" here. Of course there are race conditions if other processes modify a file when "shuf" reads or writes it, but that's true for pretty much any program that reads or writes any file, including sed -i.No, unlink/rename "sed -i" replaces the file atomically. A program that
POSIX rename assures that the destination path always exists if it already existed. If unlink/ln was used, then the destination path would temporarily be missing. While 'rename' is occuring, a second (parallel) reader/writer has no idea which version will be accessed.
Microsoft Windows and other operating systems might not support the POSIX sematic.
Certain filesystems (or their implementation) might not support atomic 'rename'.
It's mostly paranoia, but the race window _is_ there unless you use rename and break hard links.
Yes, you must use rename, and rename would need to work as per the POSIX specification.
Bob -- Bob Friesenhahn address@hidden, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
[Prev in Thread] | Current Thread | [Next in Thread] |