Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!feeder.news-service.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.os.linux.development.apps Subject: Re: mkdir() and thread safety() Date: Fri, 01 Apr 2011 16:52:50 +0100 Lines: 51 Message-ID: <87k4fe9df1.fsf@sapphire.mobileactivedefense.com> References: <9d56213c-a054-428e-866c-559da29fbbc3@o21g2000prh.googlegroups.com> <2d58ece6-bb9c-42e0-a990-fc13b92723ec@a21g2000prj.googlegroups.com> <87oc4vtn8o.fsf@sapphire.mobileactivedefense.com> <87tyejtx4u.fsf@sapphire.mobileactivedefense.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net TYhA9k3qsFvooD0w1OEDFgty4qnrAr8PAPlihhCx+ZrhQyURI= Cancel-Lock: sha1:fuPC6xH8FQI18tRIFFhySIhHtmo= sha1:RykgihENxVEHwY0Unlm+rOxnd1g= User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) Xref: x330-a1.tempe.blueboxinc.net comp.os.linux.development.apps:61 George Neuner writes: > On Thu, 31 Mar 2011 11:14:25 +0100, Rainer Weikusat [...] >>> There is no requirement for atomicity. You can't just make up requirements because >>> they seem reasonable to you. >> >>And there is also no requirement that the implementation doesn't use >>the 'file database created during booting' in the way I outlined >>above EXCEPT that this would also be a broken implementation because >>of the TOCTOU-race. Coming to think of it, it should also be okay to >>let mkdir fail randomly with EEXIST since the result is again >>identical: mkdir will or won't fail for some reason which has no >>specific relation to the state of the filesystem at the time the >>request was executed whatsoever. > > Local filesystems (typically) are designed to provide a serial > consistent view ... but distributed filesystems make other choices. > > NFS was designed to have serial (transactional) consistency similar to > a local filesystem. But there are other distributed filesystems, > e.g., AFS (CMU's Andrew file system), that provide much weaker > consistency. In the context of what is or isn't required for a standard-conforming mkdir implementation this isn't really relevant. Also, this is another 'all kinds of weird stuff are known to exist' ("Since Kennedy was shot. ...") statement. One could go so far as to call this 'FUD'. Either you have definite information that mkdir behaves in such-and-such a (non-standard conforming) way on implementation X of filesystem Z then please say so. Or you don't. Then, you are adding nothing of any use to this particular thread. [...] > Good developers have to be defensive. [...] > you cannot rely on anything in the local API. Taking this as it was stated, computers cannot be programmed at all. While you are technically correct (eg, a power outage at the wrong time or bits flipping themselves in a DRAM could produce almost arbitrarily weird effects) this is not a practical standpoint insofar 'getting something done' is the objective: This implies that the assumption that things will generally behave as they are supposed to while deviations will be rare, identifiable and 'work-aroundable' has to be made.