[boost] Re: boost::filesystem file restrictions

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-14 14:28:43

"Peter Dimov" <pdimov_at_[hidden]> writes:

> Beman Dawes wrote:
>>
>> The current approach is clearly too restrictive and isn't
>> satisfactory. Beyond the problems you mention, there really isn't a
>> single standard for portability. Even 8.3 names aren't portable to
>> systems which don't allow periods in names. A whole family of
>> checkers is needed, giving various degrees of portability. Some
>> should be supplied with the library, but users also need to be able
>> to provide their own.
>>
>> OTOH, a function that has to be explicitly called isn't going to be
>> effective. Manual checking is too laborious in code that does a lot
>> of path manipulation. A one time I took several pages of code and
>> tried to add explicit checks. The code turned into a mess. Manual
>> checking is also
>> likely to be ignored by the very programmers who need it the most;
>> those
>> who have firm but erroneous ideas about what is or isn't portable.
>
> I am not sure that it should be the responsibility of the path class to
> enforce some notion of portability. Wouldn't it be more appropriate to defer
> the portability check, if any, to the point where the path is actually used
> in a filesystem operation?

I agree.  Having portability enforcement can be useful, but AFAICT the
way it's currently supplied is biased for the 1% case. There's an
enormous class of applications which gets paths from the user or one
part of the platform implementation (e.g. a file selection dialog),
possibly does some manipulation on the path, and uses it to open some
local files on the platform.  The only category of application which
needs enforced path portability, AFAICT, is the one which stores paths
in some file meant to be used on other platforms, or arguably those
which encode paths directly in portable code.  These applications are
comparitively rare IME.  I'd rather see a path object whose default
interactions with strings treated them as platform-native, and which
had a special member function for producing a portable format.  That
function could throw if the path had no portable representation.  We
could also put a bit in the path object which said whether it should
be checked, so that all manipulations would check the path for
portability. 

        portable_path("/foo/bar") <- throws on Windows

This schema would also make paths interact better with built-in
std::iostream components.  I think it would obviate the special
fstream implementation.
             
This is also a way we could solve the whole problem of absolute paths.
It's clear that "/foo" isn't an absolute native windows path.

Maybe I'll build and post this design.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com