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
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
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
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
>-- 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
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
>-- 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
There has been some though about is_relative(path) and is_absolute(path),
>-- Function to resolve a relative path into a fully qualified absolute
Probably. I need to do some research first.
>-- Other properties of a file. size() and last_modified() are the
Thanks for the comments,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk