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

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-08-18 08:30:19

On Wed, 18 Aug 2004 10:12:36 +0000 (UTC), Martin wrote
> > 
> > A few months ago I started to write my first multi-platform application.
> > In the hope to be shielded from all kinds of filesystem specific issues,
> > I started to use boost - also for the first time - mainly because of
> > of boost::filesystem.
> 
> Interesting to hear from someone who is actually using the 
> boost::filesystem for multi-platform.
> 
> Personally I have never really understod the reasoning behind 
> the "portability" philosophy behind boost::filesystem.
> 
> Portability for me means that the code will compile and work the 
> same on different platforms. 

And it does, unless you specifically make use of platform native features by
choice.  This argument doesn't make sense to me?

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

> For me, filenames are input to the application, not a result of it! 

That's fine.

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

> >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 ;-)

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

> > However - I have found that it doesn't shield me from a LOT of filesystem
> > specific things.  In the meantime I was in the need of writing six additional
> > functions that are filesystem specific:
> > 
> > std::string native_file_string(fs::path const&);
> > void copy_file(fs::path const& source_file, fs::path const& target_file);
> > void chmod(fs::path const& filename, bool readonly);
> > bool is_readonly(fs::path const& filename);
> > void rename_file(fs::path const& source_file, fs::path const& target_file);
> > size_t get_file_size(fs::path const& filename);

Can you contribute these?  These seem like they would be nice additions to the
'convience' header.

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

HTH,

Jeff