>... > >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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
