Re: [boost] Filesystem portable path rationale and use-cases
On Tue, 2003-08-19 at 19:49, Brian Gray wrote: On Tuesday, August 19, 2003, at 12:35 AM, Yitzhak Sapir wrote: 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? This may have been covered already, but I would go further and assert that the very concept of a string path is non-portable. It does not have to be. It is legal on both Windows and *nix'es to have spaces in paths and filenames. This does not make it a good thing. I like that when I create paths that they are portable and I can use this to validate user input as well. When I have to traverse existing paths then I expect to have to use native paths. /ikh ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Filesystem portable path rationale and use-cases
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 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem portable path rationale and use-cases
On Tuesday, August 19, 2003, at 12:35 AM, Yitzhak Sapir wrote: 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? This may have been covered already, but I would go further and assert that the very concept of a string path is non-portable. For example, in the Macintosh filesystem the beginning of a full path is the name of the volume. But two volumes may have the same name, leading to ambiguity. The only good way I've seen to counter it is a concept I saw implemented in the Be API and that I recently implemented on Mac. Basically you create a VolumeRoster that enumerates the mounted volumes and their attributes, and build your path out from there until you have an Entry, which is a theoretical location that may or may not point to a Node, an actual filesystem object. Paths can be used as constructor arguments for Entry's for systems on which paths are unique, but to stay portable you obtain directories sequentially until you have the Entry you desire. This of course presumes a hierarchical file system, another portability topic that has been discussed. In addition, taking Macs into account, something my code does is get named streams on files, correlating to forks. A file by itself can be streamed into and out of, and the implementation platform is responsible for supplying a default fork for this (Mac defaults to the data fork). But you can also query the file for (and create) other forks and get their streams. Should we (do we?) have some spreadsheet enumerating various filesystem features, quirks, and limitations for whatever systems we can find, and using that as a reference regarding how to organize features like paths, file references, forks, or whatever else? It might help us to back out of the code and re-examine the problem domain regardless of the current state of Boost. -- Brian Gray ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem portable path rationale and use-cases
Brian Gray [EMAIL PROTECTED] wrote: Should we (do we?) have some spreadsheet enumerating various filesystem features, quirks, and limitations for whatever systems we can find, and using that as a reference regarding how to organize features like paths, file references, forks, or whatever else? It might help us to back out of the code and re-examine the problem domain regardless of the current state of Boost. I've been thinking that maybe the best way to provide for portable paths is to have a bunch of flags that you can set. So when you push something onto Beman's singleton stack, you can, for example, set the NTFS and VMS flags if you only care about those filesystems. However, that makes it difficult to extend to customized portability restrictions. That might require some kind of function stack within each element of the singleton stack. Then you can push the NTFS and VMS checkers onto that stack within the stack. Regards, Walter Landry [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
