[boost] Re: boost::filesystem file restrictions
Beman Dawes [EMAIL PROTECTED] writes: Yes. Plus there are some other issues. The actual interface would include boost::filesystem::path constructors which take an additional argument to explicitly specify a name checker function. In working out use cases, it seems that temporary overrides of the default function are best handled via these constructors. That leaves only the case of wishing to permanently replace the default function, and the simpler approach you are talking about would be better for that. For safety, such a set_legal_name_policy() would use the write-once-before-read idiom to avoid a dangerous global variable. (I'm actually thinking of name_check for the type, and set_name_check for the function name.) I'm about to post a message asking for opinions on the details of the policy function pointer or object. This starts to align with what I've been thinking. Every path object could maintain a chain of checkers, and combinations of path objects (e.g. via operator/) would use the union of the checkers of their components, so that checking would never become less-restrictive silently. Of course, though I think this goes against the grain of the library, I believe the default checker should always be the for the native platform. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::filesystem file restrictions
At 10:59 AM 8/18/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: Yes. Plus there are some other issues. The actual interface would include boost::filesystem::path constructors which take an additional argument to explicitly specify a name checker function. In working out use cases, it seems that temporary overrides of the default function are best handled via these constructors. That leaves only the case of wishing to permanently replace the default function, and the simpler approach you are talking about would be better for that. For safety, such a set_legal_name_policy() would use the write-once-before-read idiom to avoid a dangerous global variable. (I'm actually thinking of name_check for the type, and set_name_check for the function name.) I'm about to post a message asking for opinions on the details of the policy function pointer or object. This starts to align with what I've been thinking. Every path object could maintain a chain of checkers, and combinations of path objects (e.g. via operator/) would use the union of the checkers of their components, so that checking would never become less-restrictive silently. That is more machinery than is needed. It would be a nice design for a system that had to revisit elements, but for that isn't required here. When I was first working with designs for error checking, I tried a lot of similar schemes. Eventually I realized that treating name validity as an invariant established at construction was much simpler and performed quite well. It doesn't require keeping a chain of checkers. It performs the checking at the point in the calling program where knowledge of what is valid is present. Of course, though I think this goes against the grain of the library, I believe the default checker should always be the for the native platform. Because the native platform may support several different file systems within the same directory tree, it isn't possible to perform a full and correct lexical (inspection of the name only) check for the native platform. You in effect have to try the path and see if the operating system accepts it. What the lexical level name check done by class path is trying to do is early detection of gross naming errors. A specific example might help. Say you are working on a Linux platform. It supports a really wide range of characters in names. But you know the code sometimes will run on Windows, so you would like to check automatically that some directory tree you create doesn't violate Windows naming conventions. You do this by specifying a Windows name checker (which disallows a bunch of special characters). This will prevent your program from inadvertently using the special characters that Windows always disallows. Now when the program actually runs on a Windows box, a native path may be given (say by operator input) as the root, and then the relative portions your program adds get tacked on. If the operator supplied root happens to be a CD ISO-9660 file system, your carefully chosen relative names may fail, because the ISO-9660 names are way more restricted that general Windows names. In that case, the attempt at early detection was a failure; the name checker did no good. But a lot of real-world errors will be detected early, so I don't see the name checking as a failure. It just is a partial check, not an iron-clad guarantee. A useful axillary mechanism, but not the main show. But because it can't be an iron-clad guarantee, I'd prefer not to build an even mildly complex mechanism to support it. Particularly since some programmers will disable it anyhow. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Beman Dawes [EMAIL PROTECTED] writes:
At 10:59 AM 8/18/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
Yes. Plus there are some other issues.
The actual interface would include boost::filesystem::path
constructors which take an additional argument to explicitly specify a
name checker function. In working out use cases, it seems that
temporary overrides of the default function are best handled via these
constructors. That leaves only the case of wishing to permanently
replace the default function, and the simpler approach you are talking
about would be better for that.
For safety, such a set_legal_name_policy() would use the
write-once-before-read idiom to avoid a dangerous global
variable. (I'm actually thinking of name_check for the type, and
set_name_check for the function name.)
I'm about to post a message asking for opinions on the details of the
policy function pointer or object.
This starts to align with what I've been thinking. Every path object
could maintain a chain of checkers, and combinations of path objects
(e.g. via operator/) would use the union of the checkers of their
components, so that checking would never become less-restrictive
silently.
That is more machinery than is needed. It would be a nice design for a
system that had to revisit elements, but for that isn't required here.
When I was first working with designs for error checking, I tried a
lot of similar schemes. Eventually I realized that treating name
validity as an invariant established at construction was much simpler
and performed quite well. It doesn't require keeping a chain of
checkers. It performs the checking at the point in the calling program
where knowledge of what is valid is present.
Sure. The question is:
path x('foo/bar', portable_check);
path y('baz', native_check);
path z = x/y; // Which checks are made?
path q = z/y; // which checks are made?
Of course, though I think this goes against the grain of
the library, I believe the default checker should always be the for
the native platform.
Because the native platform may support several different file systems
within the same directory tree, it isn't possible to perform a full
and correct lexical (inspection of the name only) check for the native
platform. You in effect have to try the path and see if the operating
system accepts it. What the lexical level name check done by class
path is trying to do is early detection of gross naming errors.
Sure; I just don't want to have to be explicit about anything just to
say I'm doing native path manipulation, since I believe that's the
90% case. I don't want to be stopped by irrelevant portable path
considerations nor uglify my code to avoid it.
A specific example might help. Say you are working on a Linux
platform. It supports a really wide range of characters in
names. But you know the code sometimes will run on Windows, so you
would like to check automatically that some directory tree you
create doesn't violate Windows naming conventions. You do this by
specifying a Windows name checker (which disallows a bunch of
special characters). This will prevent your program from
inadvertently using the special characters that Windows always
disallows.
Now when the program actually runs on a Windows box, a native path
may be given (say by operator input) as the root, and then the
relative portions your program adds get tacked on. If the operator
supplied root happens to be a CD ISO-9660 file system, your
carefully chosen relative names may fail, because the ISO-9660 names
are way more restricted that general Windows names.
In that case, the attempt at early detection was a failure; the name
checker did no good. But a lot of real-world errors will be detected
early, so I don't see the name checking as a failure. It just is a
partial check, not an iron-clad guarantee. A useful axillary
mechanism, but not the main show.
No argument.
But because it can't be an iron-clad guarantee, I'd prefer not to
build an even mildly complex mechanism to support it. Particularly
since some programmers will disable it anyhow.
You need to define sensible semantics for path combinators then.
Oh, and disabling is easy:
path z = path(x, no_check)/path(y, no_check);
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::filesystem file restrictions
David Abrahams wrote: Sure; I just don't want to have to be explicit about anything just to say I'm doing native path manipulation, since I believe that's the 90% case. I don't want to be stopped by irrelevant portable path considerations nor uglify my code to avoid it. I agree except that IMO the 90+% case is I'm doing generic path manipulation which is portable path format (x/y, not x\y or x:y) but no constraints on charset except of course '/' and '\0'. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Peter Dimov [EMAIL PROTECTED] writes: David Abrahams wrote: Sure; I just don't want to have to be explicit about anything just to say I'm doing native path manipulation, since I believe that's the 90% case. I don't want to be stopped by irrelevant portable path considerations nor uglify my code to avoid it. I agree except that IMO the 90+% case is I'm doing generic path manipulation which is portable path format (x/y, not x\y or x:y) but no constraints on charset except of course '/' and '\0'. Works for me. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::filesystem file restrictions
At Saturday 2003-08-16 06:39, you wrote: Dave Gomboc wrote: For example, while it is possible to think of all drives on an MS Windows machine as being part of a single filesystem, an individual using NTFS on C:, FAT32 on D:, FAT16 on E:, and FAT12 on A: reasonably would not. Not only do I think of these drives as a single conceptual filesystem, but I don't even think of 'c:/' as conceptually top level. c:\ should map to '/My Computer/c:/', '/drives/c:/' or something similar, not '/c:/'. that's one of the reasons I suggested the anchor concept -- Rainer Deyke - [EMAIL PROTECTED] - http://eldwood.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: There oughta be a law ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Dave Gomboc wrote: For example, while it is possible to think of all drives on an MS Windows machine as being part of a single filesystem, an individual using NTFS on C:, FAT32 on D:, FAT16 on E:, and FAT12 on A: reasonably would not. Not only do I think of these drives as a single conceptual filesystem, but I don't even think of 'c:/' as conceptually top level. c:\ should map to '/My Computer/c:/', '/drives/c:/' or something similar, not '/c:/'. -- Rainer Deyke - [EMAIL PROTECTED] - http://eldwood.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: boost::filesystem file restrictions
Title: RE: [boost] Re: boost::filesystem file restrictions From: David Abrahams [mailto:[EMAIL PROTECTED]] portable_path(/foo/bar) - throws on Windows Not sure why this would throw, what is the purpose of portable_path? /foo/bar is perfectly reasonable on Windows. It's perfectly reasonable but it doesn't have a portable meaning. It is a relative path w.r.t. the drive of the current directory. Almost all paths are relative w.r.t. something, the current users filesystem mapping, the computer, the network. I don't see how leaving out the drive makes it less portable then leaving out the computer name. This is also a way we could solve the whole problem of absolute paths. It's clear that /foo isn't an absolute native windows path. This is not at all clear. I have and will contain to argue that /foo is an absolute windows path, since it does not respect the current directory. If you define anything that is not relative to the current directory as absolute, maybe you can say that. It seems perverse to say that a path which is _relative_ to something other than the machine in use is absolute, though. Also very important to me, this goes well with the URI definitions of absolute and relative I'm pretty sure this is an illusion! URIs don't have a notion of current drive do they? URIs are a multirooted system that have the semantics I'm advocating for file paths. To make an example, if you are looking at http://localhost/somedir/index.html it might have an absolute (as defined by the RFCs) href of /foo/bar that takes you to http://localhost/foo/bar and another relative (again, as defined by the RFCs) href of foo/bar that takes you to http://localhost/somedir/foo/bar. This is because paths, relative or absolute, are with respect to the authority (localhost in this case). If you can give me an example of a multirooted system that refers to paths that are absolute with respect to the current directory as relative I'd be interested, my multirooted experience is limited to CP/M, DOS, AmigaOS, OS/2, Windows, and URLs. I don't have any big system experience with them. and it would be nice if the path class could support full URIs. Are we talking about native or portable representation now? There's no reason they couldn't support full URIs in their portable representation. It's just a question of how that gets mapped onto the native filesystem. What I'm thinking of may not be in the scope of the filesystem library, I'd like a path class that could directly manipulate URLs; authoritys, fragments, options and all. Direct use of file:/.. URLs would be good too. Glen
Re: [boost] Re: boost::filesystem file restrictions
Glen Knowles wrote: This is also a way we could solve the whole problem of absolute paths. It's clear that /foo isn't an absolute native windows path. This is not at all clear. I have and will contain to argue that /foo is an absolute windows path, since it does not respect the current directory. You can argue that only because you are using the ill-defined term absolute to mean not relative to the current directory _only_, but possibly relative to some other global per-process state. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Glen Knowles [EMAIL PROTECTED] writes: From: David Abrahams [mailto:[EMAIL PROTECTED] portable_path(/foo/bar) - throws on Windows Not sure why this would throw, what is the purpose of portable_path? /foo/bar is perfectly reasonable on Windows. It's perfectly reasonable but it doesn't have a portable meaning. It is a relative path w.r.t. the drive of the current directory. Almost all paths are relative w.r.t. something, the current users filesystem mapping, the computer, the network. I find that somewhat compelling... but in the end it doesn't hold up. I don't see how leaving out the drive makes it less portable then leaving out the computer name. It's less portable because how it is to be interpreted *with respect to the filesystem* can change dynamically. Remember the name of this library, filesystem? ;- Filesystems belong to computers. A computer's filesystem is accessed via an infinite tree of names (**). How those names which correspond actual storage are mapped can be modified dynamically in any number of ways: you can have symbolic and hard links, mount drives, remote computers can come online or go away, non-storage devices can be mounted at locations in the tree etc. The one constant is the structure of the tree of names which allows us to access a virtual location in the filesystem (as opposed to physical). A path is a set of instructions for traversing the name tree. By any reasonable definition, an absolute path identifies a single virtual location in a filesystem's name tree, not one that can change based on the process state. A path on windows that starts with '/' is a set of instructions which begins: go to the root of the current directory path. That's clearly dependent on the process state. (**) You may want to say that the tree is multi-rooted, but I don't really see the point, since you can make it single-rooted by adding a common root node. Anyway, whether it's single-or multi-rooted is irrelevant to the question of absoluteness. This is also a way we could solve the whole problem of absolute paths. It's clear that /foo isn't an absolute native windows path. This is not at all clear. I have and will contain to argue that /foo is an absolute windows path, since it does not respect the current directory. If you define anything that is not relative to the current directory as absolute, maybe you can say that. It seems perverse to say that a path which is _relative_ to something other than the machine in use is absolute, though. Also very important to me, this goes well with the URI definitions of absolute and relative I disagree with that, for reasons expounded below. I'm pretty sure this is an illusion! URIs don't have a notion of current drive do they? URIs are a multirooted system that have the semantics I'm advocating for file paths. To make an example, if you are looking at http://localhost/somedir/index.html; it might have an absolute (as defined by the RFCs) href of /foo/bar that takes you to http://localhost/foo/bar; and another relative (again, as defined by the RFCs) href of foo/bar that takes you to http://localhost/somedir/foo/bar;. This is because paths, relative or absolute, are with respect to the authority (localhost in this case). Yes, an absolute URI identifies a single location in the virtual name tree. The only way to make this like a current-drive-relative path is to consider processes which are moved, *during execution*, across a network of computers. I've never heard of systems which do that that, but even if they exist I don't think they make an appropriate model on which to define the notion of absolute path in a filesystem library. If you can give me an example of a multirooted system that refers to paths that are absolute with respect to the current directory as ^^ What does that mean? And what does it mean for a multirooted system to refer to a path as relative? Do you mean in the official platform specification, or something else? relative I'd be interested, my multirooted experience is limited to CP/M, DOS, AmigaOS, OS/2, Windows, and URLs. I don't have any big system experience with them. and it would be nice if the path class could support full URIs. Are we talking about native or portable representation now? There's no reason they couldn't support full URIs in their portable representation. It's just a question of how that gets mapped onto the native filesystem. What I'm thinking of may not be in the scope of the filesystem library. I'd like a path class that could directly manipulate URLs; authoritys, fragments, options and all. Direct use of file:/.. URLs would be good too. Great idea, IMO. But yeah, I don't think it's in the scope of the filesystem library. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes:
[boost] Re: boost::filesystem file restrictions
David Abrahams wrote: Glen Knowles [EMAIL PROTECTED] writes: From: David Abrahams [mailto:[EMAIL PROTECTED] portable_path(/foo/bar) - throws on Windows Not sure why this would throw, what is the purpose of portable_path? /foo/bar is perfectly reasonable on Windows. It's perfectly reasonable but it doesn't have a portable meaning. It is a relative path w.r.t. the drive of the current directory. Almost all paths are relative w.r.t. something, the current users filesystem mapping, the computer, the network. I find that somewhat compelling... but in the end it doesn't hold up. I don't see how leaving out the drive makes it less portable then leaving out the computer name. It's less portable because how it is to be interpreted *with respect to the filesystem* can change dynamically. Remember the name of this library, filesystem? ;- Filesystems belong to computers. A computer's filesystem is accessed via an infinite tree of names (**). How those names which correspond actual storage are mapped can be modified dynamically in any number of ways: you can have symbolic and hard links, mount drives, remote computers can come online or go away, non-storage devices can be mounted at locations in the tree etc. The one constant is the structure of the tree of names which allows us to access a virtual location in the filesystem (as opposed to physical). A path is a set of instructions for traversing the name tree. By any reasonable definition, an absolute path identifies a single virtual location in a filesystem's name tree, not one that can change based on the process state. A path on windows that starts with '/' is a set of instructions which begins: go to the root of the current directory path. Correction. It does not mean that. It means go to the root directory of the current drive. It is still not an absolute path since the current drive changes. If one specified 'a:/', then that is an absolute path as defined under Windows. Even if 'a:' were a removable disk, and thus could be physically changed, it would be considered an absolute path. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Edward Diener [EMAIL PROTECTED] writes: David Abrahams wrote: A path on windows that starts with '/' is a set of instructions which begins: go to the root of the current directory path. Correction. It does not mean that. It means go to the root directory of the current drive. Is the current drive not the same as the root of the current directory? AFAICT, they are locked together. IOW, I think we were saying the same thing. I just wanted to additionally make it clear that even these paths are, in a sense, relative to the current directory. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: boost::filesystem file restrictions
Title: RE: [boost] Re: boost::filesystem file restrictions From: David Abrahams [mailto:[EMAIL PROTECTED]] Yes, an absolute URI identifies a single location in the virtual name tree. The only way to make this like a current-drive-relative path is to consider processes which are moved, *during execution*, across a network of computers. I've never heard of systems which do that that, but even if they exist I don't think they make an appropriate model on which to define the notion of absolute path in a filesystem library. The point, and this is the only one that truly compells me, is that: http://localhost/blah and /blah are absolute URL paths. c:/blah is an absolute filepath and, to be consistent, /blah should be too. If you look at a drive as equivalent to a URL authority they map very well. You can try to argue that an authority such as localhost uniquely identifies a computer, but that really isn't true. It is normal for mailcom, wwwcom, etc to all refer to the same computer, a computer used for webhosting may have thousands of such authorities. If you can give me an example of a multirooted system that refers to paths that are absolute with respect to the current directory as ^^ What does that mean? And what does it mean for a multirooted system to refer to a path as relative? Do you mean in the official platform specification, or something else? I was thinking of platform documentation, preferably an actual is_relative() system function. I've subsequently found enough examples to drop this as an argument. One thing that I hope we can agree on is that, irrespective of what they're called, we do need functions to distinguish between a:/foo, /foo, foo, and possibly a:foo. Glen
Re: [boost] Re: boost::filesystem file restrictions
David Abrahams wrote: Edward Diener [EMAIL PROTECTED] writes: David Abrahams wrote: A path on windows that starts with '/' is a set of instructions which begins: go to the root of the current directory path. Correction. It does not mean that. It means go to the root directory of the current drive. Is the current drive not the same as the root of the current directory? AFAICT, they are locked together. IOW, I think we were saying the same thing. I just wanted to additionally make it clear that even these paths are, in a sense, relative to the current directory. In addition, DOS/Windows has multiple current directories, one per drive. foo - relative /foo - absolute WRT directory, relative WRT drive c:foo - relative WRT directory, absolute WRT drive c:/foo - absolute I agree that it is possible to say that the first three are (partially) relative to the current path (the current directory of the current drive.) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Glen Knowles [EMAIL PROTECTED] writes: From: David Abrahams [mailto:[EMAIL PROTECTED] Yes, an absolute URI identifies a single location in the virtual name tree. The only way to make this like a current-drive-relative path is to consider processes which are moved, *during execution*, across a network of computers. I've never heard of systems which do that that, but even if they exist I don't think they make an appropriate model on which to define the notion of absolute path in a filesystem library. The point, and this is the only one that truly compells me, is that: http://localhost/blah and /blah are absolute URL paths. ^ ^ Portable representation c:/blah is an absolute filepath and, to be consistent, /blah should ^^^^ Nonportable, windows-specific representation be too. /blah, when taken as the portable string representation a path, is absolute. When interpreted as a native path on Windows, is anything but. If you look at a drive as equivalent to a URL authority they map very well. But they are not equivalent for any useful definition of the semantics. You can try to argue that an authority such as localhost uniquely identifies a computer, I would never argue that, and whether it's a unique identification or not is completely irrelevant to my argument. but that really isn't true. It is normal for mailcom, wwwcom, etc to all refer to the same computer, a computer used for webhosting may have thousands of such authorities. If you can give me an example of a multirooted system that refers to paths that are absolute with respect to the current directory as ^^ What does that mean? And what does it mean for a multirooted system to refer to a path as relative? Do you mean in the official platform specification, or something else? I was thinking of platform documentation, preferably an actual is_relative() system function. I've subsequently found enough examples to drop this as an argument. One thing that I hope we can agree on is that, irrespective of what they're called, we do need functions to distinguish between a:/foo, /foo, foo, and possibly a:foo. Are these supposed to be portable strings or windows strings? Unless you're very clear about that, we really can't hold any discussion. Also, if you want to distinguish those things above, why not just use string comparison? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
David Abrahams wrote: Edward Diener [EMAIL PROTECTED] writes: David Abrahams wrote: A path on windows that starts with '/' is a set of instructions which begins: go to the root of the current directory path. Correction. It does not mean that. It means go to the root directory of the current drive. Is the current drive not the same as the root of the current directory? AFAICT, they are locked together. IOW, I think we were saying the same thing. I just wanted to additionally make it clear that even these paths are, in a sense, relative to the current directory. I agree that current drive and current directory are tied to each other and that your description is technically correct. In fact, to further support you, the Windows API does not have a current drive call but rather a GetCurrentDirectory call. The VC++ and BCB RTLs do have _getdrive() calls to get the current drive, most probably from the current directory. Still the meaning of '/' in Windows refers commonly to a the root of a drive ( or volume ), and when no drive letter is given, the current drive is chosen. My correction should have been an elucidation. It still supports your notion that any path on Windows which does not specify a drive letter is considered a relative path and any path which does specify a drive letter is considered an absolute path. I am excluding in that all URI paths. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
[EMAIL PROTECTED] writes: I'm just a confused lurker seeking some clarification. I thought most OSs allowed a process filesystem to be dynamically re-rooted and that '/' refers to the current root - whatever the OS (assuming hierarchical filesystem[s]). If you introduce the extra-filesystem a:/ wrt Windows, then why not chroot for *NIXs or the 9P messages that re-root the Plan 9 filesystem to a different date or file server? I was under the impression that /foo/bar is a relative path wrt the current root of any given process state. For any given process, the physical location of /foo/bar may change between points in time and, for any two processes, the physical location of /foo/bar may be different at the same point in time. I've clearly lost the bubble here. Can someone get me started in the right direction? You're confusing physical files and paths (abstract locations). Any path may point to different physical stuff at different points in time, for a variety of reasons. If you consider /foo to be relative on *NIX then relative has no meaning because everything is relative. We may as well pick a meaning that gives the term some descriptive power. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::filesystem file restrictions
At 03:28 PM 8/14/2003, David Abrahams wrote: Peter Dimov [EMAIL PROTECTED] writes: I am not sure that it should be the responsibility of the path class to enforce some notion of portability. Wouldn't it be more appropriate to defer the portability check, if any, to the point where the path is actually used in a filesystem operation? I agree. Having portability enforcement can be useful, but AFAICT the way it's currently supplied is biased for the 1% case. There's an enormous class of applications which gets paths from the user or one part of the platform implementation (e.g. a file selection dialog), possibly does some manipulation on the path, and uses it to open some local files on the platform. Yes, of course. There is no check performed in those cases. The only names checked are on those portions of a path created via the generic grammar constructors. The check does not apply to the native constructors. The only category of application which needs enforced path portability, AFAICT, is the one which stores paths in some file meant to be used on other platforms, or arguably those which encode paths directly in portable code. These applications are comparitively rare IME. Only those cases are checked, so if they are rare in your code, then you won't experience a problem. Let me know if you run into any cases where name checking gets applied to a native path; that shouldn't be happening. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: boost::filesystem file restrictions
Title: RE: [boost] Re: boost::filesystem file restrictions We seem to be at an impasse. To summarize, you think: David Abrahams wrote: It's clear that /foo isn't an absolute native windows path. Where as I think: This is not at all clear. Glen
Re: [boost] Re: boost::filesystem file restrictions
At Friday 2003-08-15 08:35, you wrote: David Abrahams wrote: Glen Knowles [EMAIL PROTECTED] writes: From: David Abrahams [mailto:[EMAIL PROTECTED] portable_path(/foo/bar) - throws on Windows Not sure why this would throw, what is the purpose of portable_path? /foo/bar is perfectly reasonable on Windows. It's perfectly reasonable but it doesn't have a portable meaning. It is a relative path w.r.t. the drive of the current directory. Almost all paths are relative w.r.t. something, the current users filesystem mapping, the computer, the network. I find that somewhat compelling... but in the end it doesn't hold up. I don't see how leaving out the drive makes it less portable then leaving out the computer name. It's less portable because how it is to be interpreted *with respect to the filesystem* can change dynamically. Remember the name of this library, filesystem? ;- Filesystems belong to computers. A computer's filesystem is accessed via an infinite tree of names (**). How those names which correspond actual storage are mapped can be modified dynamically in any number of ways: you can have symbolic and hard links, mount drives, remote computers can come online or go away, non-storage devices can be mounted at locations in the tree etc. The one constant is the structure of the tree of names which allows us to access a virtual location in the filesystem (as opposed to physical). A path is a set of instructions for traversing the name tree. By any reasonable definition, an absolute path identifies a single virtual location in a filesystem's name tree, not one that can change based on the process state. A path on windows that starts with '/' is a set of instructions which begins: go to the root of the current directory path. Correction. It does not mean that. It means go to the root directory of the current drive. It is still not an absolute path since the current drive changes. If one specified 'a:/', then that is an absolute path as defined under Windows. Even if 'a:' were a removable disk, and thus could be physically changed, it would be considered an absolute path. I see you don't perceive changing a removable medium with changing the state of the machine (interesting perception of state). IMO, it's unfortunate everyone else seems to have ignored the Amiga's (superb) idea of using the volume label followed by a ':' as an identifier for the root on [removable] volumes. I realize that having multiple removable media w/ the same volume label still doesn't make this absolute, but it beats the snot out of what Microsoft currently provides. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: There oughta be a law ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: boost::filesystem file restrictions
Title: RE: [boost] Re: boost::filesystem file restrictions From: Peter Dimov [mailto:[EMAIL PROTECTED]] Glen Knowles wrote: This is also a way we could solve the whole problem of absolute paths. It's clear that /foo isn't an absolute native windows path. This is not at all clear. I have and will contain to argue that /foo is an absolute windows path, since it does not respect the current directory. You can argue that only because you are using the ill-defined term absolute to mean not relative to the current directory _only_, but possibly relative to some other global per-process state. Whereas you use the term to mean not relative to the current drive and directory _only_, but possibly relative to some other global per-process state (such as chroot). Which is a place you can draw the line since admittedly it must be drawn somewhere. You're mostly making an arguement that changing the current drive is sufficiently more common then changing the root or drive assignments to make it different in kind. I still find it to be significantly less common then changing the current directory, but I do see the point. Glen
[boost] Re: boost::filesystem file restrictions
Victor A. Wagner, Jr. [EMAIL PROTECTED] writes: At Friday 2003-08-15 08:35, you wrote: David Abrahams wrote: Glen Knowles [EMAIL PROTECTED] writes: From: David Abrahams [mailto:[EMAIL PROTECTED] portable_path(/foo/bar) - throws on Windows Not sure why this would throw, what is the purpose of portable_path? /foo/bar is perfectly reasonable on Windows. It's perfectly reasonable but it doesn't have a portable meaning. It is a relative path w.r.t. the drive of the current directory. Almost all paths are relative w.r.t. something, the current users filesystem mapping, the computer, the network. I find that somewhat compelling... but in the end it doesn't hold up. I don't see how leaving out the drive makes it less portable then leaving out the computer name. It's less portable because how it is to be interpreted *with respect to the filesystem* can change dynamically. Remember the name of this library, filesystem? ;- Filesystems belong to computers. A computer's filesystem is accessed via an infinite tree of names (**). How those names which correspond actual storage are mapped can be modified dynamically in any number of ways: you can have symbolic and hard links, mount drives, remote computers can come online or go away, non-storage devices can be mounted at locations in the tree etc. The one constant is the structure of the tree of names which allows us to access a virtual location in the filesystem (as opposed to physical). A path is a set of instructions for traversing the name tree. By any reasonable definition, an absolute path identifies a single virtual location in a filesystem's name tree, not one that can change based on the process state. A path on windows that starts with '/' is a set of instructions which begins: go to the root of the current directory path. Correction. It does not mean that. It means go to the root directory of the current drive. It is still not an absolute path since the current drive changes. If one specified 'a:/', then that is an absolute path as defined under Windows. Even if 'a:' were a removable disk, and thus could be physically changed, it would be considered an absolute path. I see you don't perceive changing a removable medium with changing the state of the machine (interesting perception of state). That changes the physical file(s) associated with certain paths, just like deleting and creating files or creating symlinks. It does not change where those paths refer to in the filesystem. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::filesystem file restrictions
At Friday 2003-08-15 14:03, you wrote: Victor A. Wagner, Jr. [EMAIL PROTECTED] writes: [deleted] That changes the physical file(s) associated with certain paths, just like deleting and creating files or creating symlinks. It does not change where those paths refer to in the filesystem. I'd be interested to know what you perceive to be the filesystem. It's clearly an abstract concept, but everyone seems to have assumptions about what it looks like. I suspect therein lies the current discussion. Common English words (absolute, relative, root) are being bandied about and applied to something we all see differently (the filesystem). I'm told there are systems out there that don't have hierarchical file systems (CP/M anyone? or maybe the AS-400 ummm, whatever) and apparently even systems without files (why else the committee's instance of calling them headers, header files?). For those who seem to think that a filesystem is a hierarchical collection of files with a single root (what I'm told that *NIX does), I point out that the language we're all so fond of (C++) rejected this single hierarchy for it's inheritance of classes (and I'm glad, I really don't like deriving everything from object). Perhaps we all need to merge our views of what constitutes a filesystem or descriptions of portions of it become almost meaningless). I suggest that perhaps because everyone has such strong connotive meanings attached to words like relative, absolute, and root that we not use them in such a discussion. I offer the word anchor to mean a named place in the filesystem also the concept of current directory which should probably be shortened to current paths then are either from current (no particular name for this) or from some anchor (anchored) whether a filesystem must have a single super anchor or multiple ones I leave open for discussion, tho I'm strongly in favor of multiple anchors. How all of this would be implemented should be irrelevant to the discussion (though whether it _can_ be implemented is surely a consideration) a thought on the determination of whether a path is anchored or not: define a character that cannot be used in a path _except_ to denote an anchor (I suggest ':' because it is almost an anchor marker in MS (a:, c:, etc.) and was even more so in AmigaDOS (df0:, volID13735:, sourcefiles: (AmigaDOS allows you to make up your own anchor names and place them arbitrarily in its filesystem)). -- Dave Abrahams Boost Consulting www.boost-consulting.com Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: There oughta be a law ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Victor A. Wagner, Jr. [EMAIL PROTECTED] writes: At Friday 2003-08-15 14:03, you wrote: Victor A. Wagner, Jr. [EMAIL PROTECTED] writes: [deleted] That changes the physical file(s) associated with certain paths, just like deleting and creating files or creating symlinks. It does not change where those paths refer to in the filesystem. I'd be interested to know what you perceive to be the filesystem. It's clearly an abstract concept, but everyone seems to have assumptions about what it looks like. I suspect therein lies the current discussion. It's a dynamic mapping between paths (addresses) and streams of bytes, and a set of functions for operating on those streams. Common English words (absolute, relative, root) are being bandied about and applied to something we all see differently (the filesystem). I'm told there are systems out there that don't have hierarchical file systems (CP/M anyone? or maybe the AS-400 ummm, whatever) Or ancient MacOS, before HFS. No problem. Non-hierarchical systems are addressed by paths which are a strict subset of the address space used for hierarchical systems. and apparently even systems without files (why else the committee's instance of calling them headers, header files?). True, but irrelevant AFAICT. For those who seem to think that a filesystem is a hierarchical collection of files with a single root (what I'm told that *NIX does) Not at all. It does use a hierarchical addressing scheme, which has a single root. Lots of *NIX systems have multiple drives and other physical roots under the covers. , I point out that the language we're all so fond of (C++) rejected this single hierarchy for it's inheritance of classes (and I'm glad, I really don't like deriving everything from object). Also irrelevant AFAICT. This isn't about inheritance, and when addressing the filesystem you need to start somewhere. Even in C++ all scoping starts with the global scope, ::. Your classes all live somewhere beneath that. Perhaps we all need to merge our views of what constitutes a filesystem or descriptions of portions of it become almost meaningless). Yep. I suggest that perhaps because everyone has such strong connotive meanings attached to words like relative, absolute, and root that we not use them in such a discussion. I guess you're coming to the same conclusion as the designers of the filesystem library did. I want to be able to use the traditional terms though. I offer the word anchor to mean a named place in the filesystem That sounds like what path means. also the concept of current directory which should probably be shortened to current paths then are either from current (no particular name for this) or from some anchor (anchored) whether a filesystem must have a single super anchor or multiple ones I leave open for discussion, tho I'm strongly in favor of multiple anchors. You can pick any meaning you like for your new terminology. I'm concerned with being able to use the traditional terms in a coherent and useful way. How all of this would be implemented should be irrelevant to the discussion (though whether it _can_ be implemented is surely a consideration) a thought on the determination of whether a path is anchored or not: define a character that cannot be used in a path _except_ to denote an anchor (I suggest ':' because it is almost an anchor marker in MS (a:, c:, etc.) and was even more so in AmigaDOS (df0:, volID13735:, sourcefiles: (AmigaDOS allows you to make up your own anchor names and place them arbitrarily in its filesystem)). With all of the ways that you could interpret that idea on Windows (what category is c:foo in?) I don't think I want to get involved with a determination of anchored-ness. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Beman Dawes wrote: At 06:03 AM 8/14/2003, Walter Landry wrote: It would be trivial to add an additional path constructor that takes a checking function or function object. But that would kill ease-of-use. It is one thing to require an additional constructor argument in the fairly limited use native case, but the portability checking is applied to each and every path object constructed, including the many path temporaries created by the automatic conversions from char * and string. You could have the checking functor as a pointer to a boost::function which is a default argument initialized to 0. That wouldn't kill ease of use or change anything for the users who are very happy with the current posix default. (That kill ease-of-use point might be hard to understand if you haven't actually written code using the library. The automatic conversions really do allow script-like programming ease, and are reasonably safe given the conversion result is class path.) Also, the portability checking policy often needs to propagate to called functions such as third party liberties. Adding overloads of functions to take an additional argument is also too messy, and doesn't provide for automatic pass-through to lower level functions. I think this is an excuse for a certain amount of additional rewriting of the library. How you propagate the functor pointer is your own business but we all have been faced with problems like this when adding a new feature to an implementation. Internally, do what you need to do but for the end-user I think you need to consider what is best and most flexible for him. In most (but not all) programs it really would be convenient if portability checking policy was a global. But of course we all know that global variables are consider harmful. There are also several valid use cases where a program needs to switch back and forth between portability policies. Yes, not all portability policies need to theoretically be the same. There are cases when an OS accepts a file name in one instance, such as iteratoring through wildcard names, whereas another instance it does not accept the same notation, such as determining whether or not a specific file exists. So I think you need to allow portability policies on an instance by instance basis. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Peter Dimov [EMAIL PROTECTED] writes: Beman Dawes wrote: The current approach is clearly too restrictive and isn't satisfactory. Beyond the problems you mention, there really isn't a single standard for portability. Even 8.3 names aren't portable to systems which don't allow periods in names. A whole family of checkers is needed, giving various degrees of portability. Some should be supplied with the library, but users also need to be able to provide their own. OTOH, a function that has to be explicitly called isn't going to be effective. Manual checking is too laborious in code that does a lot of path manipulation. A one time I took several pages of code and tried to add explicit checks. The code turned into a mess. Manual checking is also likely to be ignored by the very programmers who need it the most; those who have firm but erroneous ideas about what is or isn't portable. I am not sure that it should be the responsibility of the path class to enforce some notion of portability. Wouldn't it be more appropriate to defer the portability check, if any, to the point where the path is actually used in a filesystem operation? I agree. Having portability enforcement can be useful, but AFAICT the way it's currently supplied is biased for the 1% case. There's an enormous class of applications which gets paths from the user or one part of the platform implementation (e.g. a file selection dialog), possibly does some manipulation on the path, and uses it to open some local files on the platform. The only category of application which needs enforced path portability, AFAICT, is the one which stores paths in some file meant to be used on other platforms, or arguably those which encode paths directly in portable code. These applications are comparitively rare IME. I'd rather see a path object whose default interactions with strings treated them as platform-native, and which had a special member function for producing a portable format. That function could throw if the path had no portable representation. We could also put a bit in the path object which said whether it should be checked, so that all manipulations would check the path for portability. portable_path(/foo/bar) - throws on Windows This schema would also make paths interact better with built-in std::iostream components. I think it would obviate the special fstream implementation. This is also a way we could solve the whole problem of absolute paths. It's clear that /foo isn't an absolute native windows path. Maybe I'll build and post this design. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: boost::filesystem file restrictions
Title: RE: [boost] Re: boost::filesystem file restrictions portable_path(/foo/bar) - throws on Windows Not sure why this would throw, what is the purpose of portable_path? /foo/bar is perfectly reasonable on Windows. This is also a way we could solve the whole problem of absolute paths. It's clear that /foo isn't an absolute native windows path. This is not at all clear. I have and will contain to argue that /foo is an absolute windows path, since it does not respect the current directory. Also very important to me, this goes well with the URI definitions of absolute and relative, and it would be nice if the path class could support full URIs. Glen
[boost] Re: boost::filesystem file restrictions
Beman Dawes [EMAIL PROTECTED] writes:
typedef bool (*is_portable_test)( string candidate );
class scoped_portability_policy : noncopyable
{
public:
explicit scoped_portabiity_policy( is_portable_test f );
~scoped_portabiity_policy();
};
The effect of constructing a scoped_portability_policy is to push p
onto a stack. The destructor pops the stack. Class path uses the top
stack entry as the current portability checker. The stack is
initialized with a default portability checker.
Most programs which wanted a policy other than the default would just
being something like this:
int main()
{
scoped_portability_policy( posix_portability_check );
...
Although the stack is global, when coupled with
scoped_portability_policy, it is safer than a single global variable
(because library functions which push are guaranteed to pop.)
Of course it can be subverted by static or heap allocation. (Aside: Is
there a reliable way to prevent static or heap allocation?)
I'm curious to hear what others would think of the above scheme.
It's expensive to make threadsafe, since it requires a global.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Walter Landry [EMAIL PROTECTED] writes: It is a trivial change to fix this (just take out the check), and I've done this in my own copy. I'm attaching a patch with this email. I support this change. I also think it's an indicator that it might be worth rethinking and clearly defining the meaning of portable generic path. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Glen Knowles [EMAIL PROTECTED] writes: portable_path(/foo/bar) - throws on Windows Not sure why this would throw, what is the purpose of portable_path? /foo/bar is perfectly reasonable on Windows. It's perfectly reasonable but it doesn't have a portable meaning. It is a relative path w.r.t. the drive of the current directory. This is also a way we could solve the whole problem of absolute paths. It's clear that /foo isn't an absolute native windows path. This is not at all clear. I have and will contain to argue that /foo is an absolute windows path, since it does not respect the current directory. If you define anything that is not relative to the current directory as absolute, maybe you can say that. It seems perverse to say that a path which is _relative_ to something other than the machine in use is absolute, though. Also very important to me, this goes well with the URI definitions of absolute and relative I'm pretty sure this is an illusion! URIs don't have a notion of current drive do they? and it would be nice if the path class could support full URIs. Are we talking about native or portable representation now? There's no reason they couldn't support full URIs in their portable representation. It's just a question of how that gets mapped onto the native filesystem. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
