Re: [boost] boost/filesystem/directory.hpp attached for comment

From: Ross Smith (r-smith_at_[hidden])
Date: 2002-03-22 10:54:55

Beman Dawes wrote:
> 
> At 05:42 AM 3/21/2002, Ross Smith wrote:
> 
>  >-- is_read_only() is nontrivial on Unix, where it would require
>  >complicated checking on user identity, group membership, etc. If the
>  >comment "doesn't imply writable; permissions or the like may make a
>  >non-read-only file still not writable" was intended to cover this, and
>  >to imply that only one (which one?) of the permission bits is checked,
>  >then I can't see the point of having the function at all.
> 
> Ugh. I wasn't very clear.
> 
> How about this:
> 
> !is_read_only() doesn't imply writing to the file will succeed. The intent
> is, however, that opening a !is_read_only() file for output would succeed
> as long as there weren't errors unrelated to read/write status. A usage
> example would be opening a file for reading only if read-only (such as on a
> CD-ROM), but otherwise opening for both reading or writing.

Sorry, I still don't get it. If !is_read_only() doesn't imply writable,
what _does_ it imply? I don't understand what the function is actually
supposed to tell you.

Does it mean "has the read-only bit set"? Ambiguous at best, since files
on Unix have three write-permission bits, and determining which one is
relevant to the current process is both nontrivial and nonportable. If
you arbirarily pick one of them and simply have the function return
that,
or some similar hack such as returning true only if none of the write
bits are set, it would be useless.

Does it mean "on a read-only file system" (as your CD exaple suggests)?
Of very doubtful utility, not to mention even more complicated and
nonportable than the above.

I'm afraid you're going to have to explain the exact semantics of
is_read_only() in more detail before we can make any fair juddgements
about it.

>  >-- There are several versions of "remove" covering various combinations
>  >of file vs directory, remove recursively vs throw if not empty, remove
>  >if exists vs throw if not, but I can't see one for "remove this object,
>  >regardless of whether it's a file or directory; if it's a directory,
>  >remove recursively; if it doesn't exist, silently do nothing" (i.e. the
>  >equivalent of rm -rf), which strikes me as by far the most common
>  >desired semantics.
> 
> Yes, that functional is missing.  It's deliberate because that operation
> seems somewhat unsafe to me, and the interface was getting fat.

But it's the really useful one. From my point of view, that's the normal
semantics I want for "remove"; the other variations are rare enough that
implementing them by hand as needed would be acceptable. But if I have
to write complicated and unreliable (see race condition comment
elsewhere in thread) code to get the most common case, the library is
badly broken.

>  >-- What's the difference between is_file() and existing_file() (and
>  >ditto for ..._directory())?
> 
> The inconsistency is to favor of usability.

<blank look> Er ... once more, please, in English?

>  >-- I'm not sure what prune() does. Putting together clues from the
>  >surrounding material, I'm guessing that it removes the contents of a
>  >directory but not the directory itself. That seems a very arcane and
>  >unusual operation to me; is it really common enough to be worthy of a
>  >function in its own right?
> 
> Since a filtered remove (which is what prune does) by definition may leave
> some contents in the directory, trying to then remove the directory would
> fail (because the directory might not be empty.)  It's like saying "del
> *.wrk" or "rm *.wrk" - you wouldn't expect the current directory to also be
> deleted!

In that case, I can't see the point of the first two versions of
prune(). Perhaps I'm still not understanding your description, but it
sounds like an operation that intrinsically involves a filter, and makes
no sense without one.

>  >-- "Rationale for not providing name, regex, or predicate filtered
>  >versions of remove() or remove_all(): The implication of filtering is
>  >that the starting directory may not be empty on completion of
>  >operations. Thus trying to remove it makes no sense." I'm sorry, I just
>  >can't understand what you're driving at here. Why would it be
>  >undesirable to be able to easily remove only files that match a
>  >condition? I would have thought it would be not only desirable but very
>  >common.
> 
> Same as above.  You do want to be able to remove the files.  That's what
> prune does.  If you want to take the directory out too, use
> remove_all.  But  it makes no sense to first removes some files, then
> removes the rest of the files, then delete the directory.  You either want
> the directory and entire contents removed, or you want some of the contents
> removed, but not the directory itself.

Sorry, I'm still completely lost here. I still don't understand why
"remove all files that match this pattern|predicate" would not be
useful. If the answer is "it is sueful, that's what prune() does" (which
I _think_ is the case from your description of prune() above, but I'm
not certain), then what was the rationale supposed to justify -- what
functionality is missing whose absence you were explaining?

>  >-- Related to some of the above, I see a general pattern of providing
>  >non-recursive and (sometimes) recursive versions of operations, and
>  >treating the non-recursive case as the normal case and the recursive one
>  >as a less prominent variation (when it's provided at all). I would have
>  >thought it would be the other way around -- usually, the recursive case
>  >is the one I want nearly all the time, and the non-recursive case is the
>  >weird special case that's hardly ever useful and often not worth
>  >bothering to provide a single function for.
> 
> I'm sorry, but I've seen far too many disasters when recursive operation is
> the default.  Would you really want "del *.txt" to be recursive?

Well, I wouldn't expect *.txt to match a directory name so that
particular example is a non-issue. But if I was using a pattern that I
expected to match a directory, then I certainly would want it to be
recursive. Making me stop and manually delete all the directory contents
first would just be a pointless and annoying waste of time.

-- 
Ross Smith ...................................... Auckland, New Zealand
r-smith_at_[hidden] ....................................................
  "We need a new cosmology. New gods. New sacraments. Another drink."
                                                       -- Patti Smith