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

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-08-18 11:05:06

On Wed, 18 Aug 2004 14:41:19 +0000 (UTC), Martin wrote
> >> 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.

All server/daemon type applications.  'Script-type applications' that use
relative paths from the point of invocation and thus don't require user input.
 I've written gobs of these.

> 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.

It's a big thing to me.

> >> 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.

Sure, it might come from a config file, but that doesn't mean the path can't
be relative and structured such that the config file is portable too.  I don't
want to maintain different config files for different platforms.  There are
all sorts of mistakes one might make with filenaming and it's nice to not have
to test on all platforms to find that out.

> >>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.

I don't disagree that if you are taking user input, native paths might be the
more 'portable approach'.  I was lamely trying to make a joke...

> > > 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.

Yep the docs give the wrong impression.  But please read this:

http://lists.boost.org/MailArchives/boost/msg60423.php

 
> > > 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.

Ok, I misunderstood your first point.  Anyway, it seems to me that the main
'problems' you are having are additional features that need to be contributed...

Jeff