Re: [boost] filesystem/directory.hpp header redux

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-26 21:41:10

At 04:12 PM 3/26/2002, Ross Smith wrote:

 >-- You're still blithely ignoring the massive difficulty (impossibility
 >without great gobs of nonportable code) of implementing is_readonly() on
 >unixoid OSes.

I'm not ignoring it; I'm waiting to hear from UNIX/POSIX implementors to 
see if others also think it is a problem.  It isn't the world's most 
important function, and I'll be happy to drop it if others agree it can't 
reasonably be implemented.

 >"!fopen(path,"a+")" is neither a useful specification (what if there's
 >no more room on the disk?)

The point is you know that trying to open the file for writing will fail, 
so you can fall back to a read-only strategy.  It doesn't matter why.  It 
doesn't matter that a file may start out writable, but then fail because of 
later disk space problems.

 > nor a useful implementation (it would change
 >the file's modification date if it's writable).

Only on O/S's that forced an implementor to actually attempt an open.  And 
the intended use is to see if some kind of modification has a chance of 
success.  So the file mod date is likely to be modified right away anyhow.

 >-- What does is_empty() do? The name doesn't suggest anything to me. (If
 >it's size==0, why isn't there a size() function?)

For a file, it's in effect size(path)==0. For a directory (which is the 
particularly use case), it is 
directory_iterator(path)==directory_iterator().

is_empty() will turn out to be particularly useful if the size attribute is 
not universally available, or is not available for directories.

In an ideal world, boost/filesystem/directory.hpp, 
boost/filesystem/attribute.hpp, and boost/filesystem/path.hpp would all be 
designed together.  But that wasn't happening.  So I've tried to nail down 
a reasonable directory.hpp interface.

Hopefully, Jan now has a known context for his work on file 
attributes/properties.

And we do need to nail down boost/filesystem/path.hpp.  The trick there is 
to do it in a way that will work with operating systems well beyond the 
POSIX/Windows orbit.

 >-- create_directory() needs an option to create any necessary parent
 >directories (mkdir -p). At least, I don't think it does that now; it's
 >hard to tell from your description (branch? leaf?).

That's what the "recurse" option would do.

 >
 >-- There's a move() but no copy(). Oversight?

Cut-and-paste error.  Did the cut, forgot the paste.  Luckily, have backup!

 >-- In the interests of generality, if you're only going to provide one
 >conditional-delete function, it really needs to be the predicate one,
 >not the regex one.

Yes, the predicate one would be more general.  But for the "script-like" 
target use, regex is probably the most common usage.  People can hand code 
other uses, I'm assuming.

Whether or not that is a good decision really won't be totally obvious 
until people use the interface in real work.  Easy enough to add predicates 
later.

Lambda really makes the predicate form more attractive, too.

 > The latter is trivial given the former, but if you
 >only have the latter, anything else has to be hand-coded. On the other
 >hand, I'm dubious about the need for selective-delete operations in
 >general: hand-coding them is easy; I don't see any reason why
 >selective-delete would be more useful than any of the other
 >selective-whatever functions that aren't there; and I can think of any
 >number of operations that I'd put in a file handing library before
 >selective-anything.
 >
 >-- Top of that list would be is_ordinary_file() vs is_special_file().

Those will be high on the attribute/properties list perhaps, but I'm not 
sure they deserve special is_xxx() functions.

 >Others I'd like to see (from a quick vgrep through my own code):
 >
 >-- Functions to split a path into its component parts. (Is this what
 >branch + leaf do?)

boost/filesystem/path.hpp will provide functions to lexically operate on 
paths.

There has been some though about is_relative(path) and is_absolute(path), 
too.

 >-- Function to resolve a relative path into a fully qualified absolute
 >path.

Probably.  I need to do some research first.

 >-- Other properties of a file. size() and last_modified() are the
 >obvious ones.

Attributes/properties.  Coming.

Thanks for the comments,

--Beman