Re: [boost] Handling unix-characters with boost::filesystem (bug 776146)

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-07-24 20:05:56

At 11:21 AM 7/23/2003, Erkki Seppala wrote:

 >...
 >
 >As this behavior (handling certain characters differently on systems
 >that can handle them) seems to be a designed feature, I must raise my
 >concern that I really don't want to see a generation of unix-programs
 >that fail to handle some files I have in my hd. The program above
 >would seem to me to be perfectly portable even if had the ability to
 >handle all kinds of characters in filenames. (I wouldn't want to
 >resort to using some depreciated native-interfaces to accomplish that
 >either.)

The native interface isn't intended to be deprecated. It has many valid 
uses, such as for handling operator input supplied paths.

 >And answering to Vladimir Prus on the bug report: I would hate to see
 >a program that was not able to create, manipulate and unlink certain
 >files, just for the sake that some other platforms have problems with
 >those characters. Handling files called ' ', '"*?' isn't a problem for
 >me. I have almost a 1000 files with character : (perl manual-pages)
 >and some with letters < and >.. (think message-id's)

It sounds to me as if you are dealing with many files with names that you 
do not expect to be portable even to POSIX systems, let alone portable to 
completely unrelated operating systems. (I say that because the POSIX 
portable filenames are limited to 0-9, a-z, A-Z, '.', '_', and '-'.)

If so, what is the interest in a portable library? Why not just use the 
native API available for your operating system?

That being said, there is a long-standing issue as far as existing files 
go. The native names should be supported for existing files even if they 
are not likely to be portable. This works currently to some extent, but not 
as fully as it could and should.

 >(Btw, why is this a library-issue at all anyway? I'm sure the
 >operating system is more than pleased to tell the program that the
 >filename is invalid.)

There are two kinds of portability; syntactic portability and semantic 
portability. Semantic portability implies that not only the form of library 
calls is portable (syntactic portability), but also the behavior. Syntactic 
portability without semantic portability provides only an illusion of 
portability.

It's a complex issue, but the intent of the filesystem library is that the 
default should be for behavior that is as portable as reasonably possible 
without requiring heroic efforts on the part of implementors.

Thanks for the comments,

--Beman