[boost] Filesystem portable path rationale and use-cases

From: Yitzhak Sapir (yitzhaks_at_[hidden])
Date: 2003-08-19 02:35:24

This discussion started off with various questions, including the following:
1) Why does it implement any restrictions, by default, on what kind of files it allows?
2) I don't understand why boost::filesystem wants to restrict me to a set of filenames that are portable

But the discussion quickly changed to deal with how to support more complex "portability" schemes.  I think that's important once a more basic question is answered:  What is the rationale for trying to achieve a portable path in the first place and what are the use-cases where such a portable path is useful, and cannot be solved by better means?  I tried to think up such use cases, but in those I could think up, I think the "need" for a "portable" path is flawed.  In our own use of the filesystem paths, we always use native paths, and read in values from configuration files.  It's simply not practical to expect the user to provide a relative path from wherever the program is installed somewhere in "C:\Program Files", to C:\Log or something of this sort.

I can consider several situations or use-cases:
1) A programmer hard-codes a path into the source.  So this is to prevent him from hard-coding a non-portable path, helping ensure that the resultant program will be portable.  However, if the programmer was concerned about portability in the first place, he would place paths in configuration files, so that they could be configurable.  If he isn't concerned about portability, then nothing will prevent him from hardcoding a path and using boost::filesystem::native.

2) A programmer reads paths in input from the keyboard, or elsewhere, such as File->Open.  However, this is not inherently non portable.  Depending on the operating system where the code is run, "File->Open" or equivalent will/should return a proper native path for that system.  The code itself is still portable.

3) Program data files are placed on various directories relative to the program's executable directory, and the program uses relative paths to its executable directory to access those data files.  But the actual relative paths will usually be different for different operating systems anyhow.  "c:\program files" as opposed to /usr/local or /bin.  In fact, it might even be different for a single operating system but different installation setup (for example, "d:\program files", and even though I am less acquainted with unix, I'm sure that there are similar examples in unix).  The right thing in my opinion is to put these into configuration files or (in Windows) the registry and read them when run.  

Of course, in that case, the configuration file path would have to be specified, since it's probably in a configuration directory and not where the executable resides.  But the question of how to figure out the configuration file's path isn't going to be solved by forcing portable pathnames.  In fact, the question of whether to read it from a file is itself system specific, because on windows, you'd most likely want to read it from the registry.  And if it's not in the registry, it's probably hidden in some "Application Data" directory or what not.  On unix it might be in the user's home directory ("~/.programrc") or someplace similar.  In order to deal with this the programmer will have to code non-portable code anyhow, compiling a "windows_configuration_data_reader.cpp" in windows and a "unix_configuration_data_reader.cpp" in unix.  Or it might be just more easily solved by passing the configuration pathname location as a program argument.

4) Paths from one system are serialized over a stream (file, tcp/ip, etc) and read on another system.  But who is to say that the path, even if it conforms to concepts of portability, will be valid on that other system?  Consider the examples above for "c:\program files" vs. "d:\program files" vs /usr/local.

My feeling from all these examples is that a path string is inherently specific to the system for which it was specified, and can't really be ported to anywhere else.  Much like a string is usually inherently specific in its encoding to the system-specified encoding.  However, the filesystem library can provide a portable way to manipulate this system specific path, much like the string library provides a portable way to manipulate the system-specific encoded string.  In view of this, why try for a "portable path" at all? 

Yitzhak