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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-18 20:48:01

At 04:56 PM 3/18/2002, dylan_nicholson wrote:

 >>From what I've seen on this thread, of all the different scenarios in
 >which various remove failures can be safely ignored, none stand out
 >as so common as needing their own "convenience" function.  As it is,
 >it's 4-5 lines of code to write your own wrapper around what boost
 >provides.

Some of the convenience functions are even smaller than that; I think the 
recursive remove and copy are the only two with any serious meat in 
them.  The (maybe four to six) others are pretty simple.  But the objective 
is to be able to write "script-like" programs, so a bit of convenience will 
likely be appreciated by users.  But its also easy to remove them if people 
don't like them.

 >  Just for the record, most of the times I have used remove,
 >I've literally not cared at all whether there was an error, no matter
 >what it was.  The "file in use" error in particular is one that I
 >know I can safely ignore (sometimes I might retry a couple of times).
 >But to start picking and choosing arbitrarily which errors should
 >throw exceptions seems a questionable task at this stage anyway.

I don't think the error to be ignored (!exists()) is that arbitrary.  Both 
Rob Stewart looked at the problem and came to the same conclusion.

 >  The
 >first cut of the library can get by fine with just a 'remove' that
 >throws exceptions on all possible errors

Yes, that is the plan for the basic remove operation.

 > - if there really is a
 >strong demand for one that avoid some exceptions, then we can look at
 >it then.  And it may not be just remove - it's conceivable that other
 >filesystem operations need similar treatment.
 >
 >As for the temporary file case, there's actually a good argument for
 >a RAII-style "temporary file" and "temporary directory" class (I've
 >used them quite a bit myself).  As it is I don't think there has been
 >a proprosal to support things like tmpnam etc.

I'm also inclined to think temporary names (or unique names) will be 
needed.

I had to provide similar functionality years ago, and found that a 
guaranteed unique name based on a hint was much more useful that names like 
temp0345.

--Beman