RE: [boost] Re: Filesystem library: remove / etc

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-20 11:13:03

At 09:35 AM 3/20/2002, Brey, Edward D wrote:
 >> From: Beman Dawes [mailto:bdawes_at_[hidden]]
 >>
 >> Like all I/O, directory operations are subject to unexpected
 >> errors.  Consider the following assert, which may fail even in a
 >> non-threaded environment:
 >>
 >>     assert( exists( "foo" ) == exists( "foo" ) );
 >>
 >> I don't see anything to do about these problems except to
 >> warn people that
 >> the problems may occur.
 >>
 >> Does anyone have a better idea?
 >
 >I think the answer is to rely on the built-in atomic capabilities of the
 >operating system.  For example, when you proposed, IIRC,
 >
 >void remove_if_exists(string file) {
 >  if (exists(file))
 >      remove(file);
 >}
 >
 >this thought came to mind, because I assumed that we were just ignoring 
the
 >issue for sake of simplicity of conversation.  To eliminate the race
 >condition, one would really implement it more like this:
 >
 >void remove_if_exists(string file)
 >{
 >  switch (error_type os_specific error = os_specific_remove(file))
 >  {
 >      default: throw file_exception(os_specific_error);
 >      case success:
 >      case file_does_not_exist:
 >  }
 >}
 >
 >Am I right in understanding that a function like Win32 DeleteFile can be
 >counted on to serialize its operations with other OS operations that 
affect
 >the same file, so that if it says that the file does not exist at remove
 >time, then that truly is the case?

While a quality implementation can (and should) minimize the chance of race 
conditions by using atomic operations where possible, I don't see how we 
can specify that as a requirement.  Remember that the file involved might 
be on a very remote network, odd-ball physical device, use an unusual file 
system driver, etc.

 >I think that you're remove_if_exists idea is a great way to handle the
 >common case of not caring whether a deleted file was present without 
having
 >to resort to the error-prone ways of old of returning a (too often
 >incorrectly left unchecked) success/failure code.

Well, it wasn't entirely my idea; it was also suggested by Rob Stewart 
IIRC.

--Beman