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