[Boost-users] Re: boost::filesystem problems

From: Martin (adrianm_at_[hidden])
Date: 2004-08-18 09:41:19

>> Strangly enough boost::filesystem works 
>> activly against this by enforcing that you use "portable" filenames 
>> (unless you specificly turn it off).

>Exactly.  In many cases, making a completely portable application goes beyond
>compilation and includes the form of the data -- namely the file paths.  There
>are many applications where the developer wants to ensure that the paths will
>work on all platforms without having to actually test on them.

Can you give an example of such an application because I have difficult to 
picture an application that will on purpose not accept all paths that are 
valid on the operating system where it runs.

The only use I can see is that you at run-time can ensure that some 
application generated paths (e.g. path(root / "mysubdir")) are portable but 
why base an entire library on such a small thing.

>> Why would I want to force a windows user to only enter filenames 
>> that are portable?

>That works for your application, but not for others.  You are taking user
>input and want native paths.  I think this option is clearly documented in the
>library.

as above. Why would an application work with paths that don't come from user 
input or a configuration file.

>>From a user perspective native_file_string() is portable while string() 
isn't 
>> since it doesn't present the path in a way that the user recognize.
>Perhaps they need to be educated 

I saw the smiley but don't understand if you agree or not.

> > Same thing with wide-character filenames. Why should 
> > boost::filesystem::path care if the path it carries is in a 
> > std::string or std::wstring? The wide- character filesystem 
> > operations can be difficult/impossible to implement on some systems 
> > but so are probably other operations. The alternative today is to 
> > not use boost::filesystem at all.
> 
> This is simply a question of timing.  Beman had been working on a wide string
> extension for the library.  I don't know where it stands, but clearly his
> intent is to add this capability. My understanding is he is recovering from 
an
> illness and is not following the list at the moment.

>From the FAQ:
"Wide-character names would provide an illusion of portability where 
portability does not in fact exist. Behavior would be completely different on 
operating systems (Windows, for example) that support wide-character names, 
than on systems which don't (POSIX). Providing functionality that appears to 
provide portability but in fact delivers only implementation-defined behavior 
is highly undesirable. Programs would not even be portable between library 
implementations on the same operating system, let alone portable to different 
operating systems."

>From that I understood that wide-character support is against the portability 
philosphy and will not be implemented. Didn't know that someone is working on 
it.

> > Add to that the possibility to only iterate over specific files like 
> > "*.txt". Only the filsystem knows if "file.TXT" matches "*.txt" so 
> > the directory_iterator can't be used for this simple case
> 
> Search the developer mailing list for 'globbing iterator' and you should find
> links to a package that does this.  It's not officially part of boost, but I
> think the author was planning on trying to include it.

As I said: 'Only the filsystem knows if "file.TXT" matches "*.txt"'. No 
external function can work it out by just looking at the filename.
One example: Under Win32 you can have both case insensitive and case sensitive 
files even in the same directory (depending on a POSIX_somthing file 
attribute). AFAIK the only way to know which files matches "*.txt" is to 
pass "*.txt" to "FindFirstFile" but the directory_iterator always uses "*".
I assume the situation is the same if you mount some case-insensitive 
filesystem under posix.