<?xml version="1.0" encoding="utf-8"?><!-- generator="wordpress/2.0.11" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Ride on a White Horse</title>
	<link>http://log.emmanuelebassi.net/archives/2006/07/ride-on-a-white-horse/</link>
	<description>Random babblings of a geek.</description>
	<pubDate>Wed, 08 Oct 2008 07:05:34 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.11</generator>

	<item>
		<title>by: Jonathan Allen</title>
		<link>http://log.emmanuelebassi.net/archives/2006/07/ride-on-a-white-horse/#comment-9444</link>
		<pubDate>Tue, 25 Jul 2006 17:41:19 +0000</pubDate>
		<guid>http://log.emmanuelebassi.net/archives/2006/07/ride-on-a-white-horse/#comment-9444</guid>
					<description>I am not arguing that your code isn't more robust. Rather, I am suggesting that it is solving the wrong problem.

While your solution does help somewhat, it doesn't solve the underlying problem of other programs messing with your directories. Solve that, and your solution becomes moot.</description>
		<content:encoded><![CDATA[<p>I am not arguing that your code isn&#8217;t more robust. Rather, I am suggesting that it is solving the wrong problem.</p>
<p>While your solution does help somewhat, it doesn&#8217;t solve the underlying problem of other programs messing with your directories. Solve that, and your solution becomes moot.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Raphaël Quinet</title>
		<link>http://log.emmanuelebassi.net/archives/2006/07/ride-on-a-white-horse/#comment-9393</link>
		<pubDate>Mon, 24 Jul 2006 19:42:19 +0000</pubDate>
		<guid>http://log.emmanuelebassi.net/archives/2006/07/ride-on-a-white-horse/#comment-9393</guid>
					<description>&lt;blockquote cite="Marius Gedminas"&gt;
It would be more precise to say “did indeed exist at the moment of the syscall”. Someone might have deleted it since then.
&lt;/blockquote&gt;

It is harder to exploit a race condition requiring the deletion and re-creation of a directory.

If the parent directory has the "sticky bit" set (like for /tmp), then it will not be possible for other users to delete or rename that sub-directory, so the operation is safe.</description>
		<content:encoded><![CDATA[<blockquote cite="Marius Gedminas"><p>
It would be more precise to say “did indeed exist at the moment of the syscall”. Someone might have deleted it since then.
</p></blockquote>
<p>It is harder to exploit a race condition requiring the deletion and re-creation of a directory.</p>
<p>If the parent directory has the &#8220;sticky bit&#8221; set (like for /tmp), then it will not be possible for other users to delete or rename that sub-directory, so the operation is safe.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Marius Gedminas</title>
		<link>http://log.emmanuelebassi.net/archives/2006/07/ride-on-a-white-horse/#comment-9392</link>
		<pubDate>Mon, 24 Jul 2006 18:59:23 +0000</pubDate>
		<guid>http://log.emmanuelebassi.net/archives/2006/07/ride-on-a-white-horse/#comment-9392</guid>
					<description>&lt;blockquote cite=""&gt;At the end of the if block we are guaranteed that the file or the directory does indeed exist [...]
&lt;/blockquote&gt;

It would be more precise to say "did indeed exist at the moment of the syscall".  Someone might have deleted it since then.

Nevertheless your code is more reliable than the original one.</description>
		<content:encoded><![CDATA[<blockquote cite=""><p>At the end of the if block we are guaranteed that the file or the directory does indeed exist [&#8230;]
</p></blockquote>
<p>It would be more precise to say &#8220;did indeed exist at the moment of the syscall&#8221;.  Someone might have deleted it since then.</p>
<p>Nevertheless your code is more reliable than the original one.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: ebassi</title>
		<link>http://log.emmanuelebassi.net/archives/2006/07/ride-on-a-white-horse/#comment-9391</link>
		<pubDate>Mon, 24 Jul 2006 18:36:29 +0000</pubDate>
		<guid>http://log.emmanuelebassi.net/archives/2006/07/ride-on-a-white-horse/#comment-9391</guid>
					<description>sorry - I must be on crack. my code does not have the race condition: if the syscall fails, then we are inside the error trap and we can gracefully exit; if the syscall succeds then we are safe.

the race condition of the test-then-do code is that there's a gap between the test and the actual syscall; trapping the error when the test fails is much more harder and makes the code uglier (you have to check twice: one for the test and one for the syscall).</description>
		<content:encoded><![CDATA[<p>sorry - I must be on crack. my code does not have the race condition: if the syscall fails, then we are inside the error trap and we can gracefully exit; if the syscall succeds then we are safe.</p>
<p>the race condition of the test-then-do code is that there&#8217;s a gap between the test and the actual syscall; trapping the error when the test fails is much more harder and makes the code uglier (you have to check twice: one for the test and one for the syscall).
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: ebassi</title>
		<link>http://log.emmanuelebassi.net/archives/2006/07/ride-on-a-white-horse/#comment-9389</link>
		<pubDate>Mon, 24 Jul 2006 18:10:07 +0000</pubDate>
		<guid>http://log.emmanuelebassi.net/archives/2006/07/ride-on-a-white-horse/#comment-9389</guid>
					<description>&lt;b&gt;jonathan&lt;/b&gt;: while it's true that there can be a race inverse to the one that I exposed, the code is nevertheless more robust: the check-then-do moves the burden to userspace and the programmer, while the do-then-deal-with-error moves the burden to the kernel.

and trying to create a directory and failing is, at most, going to cost you the same as the stat() that g_file_test() performs, only that - if the underlying C library is doing thinks right - you get one less indirection (mkdir -&gt; return EEXIST vs. g_file_test -&gt; stat -&gt; check against flags -&gt; return).</description>
		<content:encoded><![CDATA[<p><b>jonathan</b>: while it&#8217;s true that there can be a race inverse to the one that I exposed, the code is nevertheless more robust: the check-then-do moves the burden to userspace and the programmer, while the do-then-deal-with-error moves the burden to the kernel.</p>
<p>and trying to create a directory and failing is, at most, going to cost you the same as the stat() that g_file_test() performs, only that - if the underlying C library is doing thinks right - you get one less indirection (mkdir -> return EEXIST vs. g_file_test -> stat -> check against flags -> return).
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Jonathan Allen</title>
		<link>http://log.emmanuelebassi.net/archives/2006/07/ride-on-a-white-horse/#comment-9387</link>
		<pubDate>Mon, 24 Jul 2006 17:47:54 +0000</pubDate>
		<guid>http://log.emmanuelebassi.net/archives/2006/07/ride-on-a-white-horse/#comment-9387</guid>
					<description>Your solution to what you call an "implicit race condition" is wrong.

While it is true that someone can come in during that split second and create the directory, they can also delete that directory immediately after you create it. Thus you have not fixed anything.

The correct solution is to create a private directory system that your program controls. Sure there is no guarantee that a rogue program isn't going to damage your program's bit of the file system, but this gets you a lot closer than trying to perform atomic directory creation.

Also, what is the cost of trying and failing to create a directory versus just checking to see if it exists? In order to show your solution doesn't cause more harm than good, you need to investigate that aspect.</description>
		<content:encoded><![CDATA[<p>Your solution to what you call an &#8220;implicit race condition&#8221; is wrong.</p>
<p>While it is true that someone can come in during that split second and create the directory, they can also delete that directory immediately after you create it. Thus you have not fixed anything.</p>
<p>The correct solution is to create a private directory system that your program controls. Sure there is no guarantee that a rogue program isn&#8217;t going to damage your program&#8217;s bit of the file system, but this gets you a lot closer than trying to perform atomic directory creation.</p>
<p>Also, what is the cost of trying and failing to create a directory versus just checking to see if it exists? In order to show your solution doesn&#8217;t cause more harm than good, you need to investigate that aspect.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
