Re: [boost] [filesystem] adding path equality and path equivalence

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-02-02 08:46:57

At 11:19 PM 2/1/2004, Jeremy Maitin-Shepard wrote:

 >Beman Dawes <bdawes_at_[hidden]> writes:
 >
 >> At 05:51 PM 2/1/2004, Jeremy Maitin-Shepard wrote:
 >
 >> [snip]
 >
 >>> I would suggest that the function throw an exception if either file
 >>> does not exist.  The exception would allow the user to determine
 >>> exactly which paths exist or do not exist.  Any other behavior, given
 >>> that the function can return only true or false, would in some
 >>> circumstances give the user less information than desired.
 >
 >> Regardless of what the function does, the user can always call
 >> exists() beforehand if a complete understanding of what is present and
 >> what isn't is required.
 >
 >Yes, but using two separate calls introduces race conditions.

Currently, the possibility for this kind of race condition occurs in a 
number of places within the library. AFAIK, every function which uses more 
than one system call to accomplish behavior has the problem.

 >Filesystem race conditions, which can be a source of security
 >vulnerabilities in programs, are extremely common, and I think it is
 >important for this library to discourage them.

I'm intrigued by your idea in a prior posting of holding an open handle 
whenever such multiple system calls are needed, to prevent race conditions. 
There are actually two cases I can see, (1) where we wish to prevent 
deletion of a file, and (2) where we wish to prevent creation of a file. I 
see how your technique could prevent (1) but not (2). Even so, (1) is 
enough of a worry that the technique is well worth thinking about.

Coming back to equivalence, I still like John Maddock's suggestion of 
throwing only if both do not exist. If fits my intuitive sense of what 
"equivalence" means for files and directories. However, such thoughts in 
the past sometimes changed when tests cases were being constructed. So no 
firm decision has been made yet.

Thanks,

--Beman