Re: [boost] Re: Filesystem portable path rationale and use-cases
David Abrahams <[EMAIL PROTECTED]> wrote: > Walter Landry <[EMAIL PROTECTED]> writes: > > > 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. > > I _really_ hope we don't have any singleton stack which affects path > validation. It sounds like a nightmare for any application involving > threads. I think I finally understand what the problems with multiple threads are. You are worried that one thread's portability checking will be changed midstream by another thead. Sounds hairy. So one solution is to make the portability checking local to a thread. I don't have a feel for how to implement that, and it does seem to introduce complexity where it isn't always needed. Regards, Walter Landry [EMAIL PROTECTED] ___ 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
Re: [boost] boost::filesystem file restrictions
"Peter Dimov" <[EMAIL PROTECTED]> wrote: > 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, if only because I could imagine manipulating a bunch of non-legal paths before actually using a legal one. We still have to solve the problem, but at a different place. Beman's singleton stack seems like a reasonable solution. We can argue over what the default portability policy should be, but it almost becomes irrelevant because it is easy to change and forget about it. Regards, Walter Landry [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::filesystem file restrictions
Greetings,
I've started using boost::filesystem recently, and I'm mostly very
happy. One thing bothers me, though. Why does it implement any
restrictions, by default, on what kind of files it allows? From the
documentation:
The following are not valid name char's: x01-x1F, <, >, :, ", /, \,
|, *, ?. Although these characters are supported by some operating
systems, they are disallowed by so many operating systems that they
are banned altogether.
I also noticed that you can't open a directory named "." or "..",
though I think "./" and "../" both work. Files starting or ending
with spaces also don't work.
I understand that I can (painfully) work around it by using a
different context, but I don't understand why boost::filesystem wants
to restrict me to a set of filenames that are portable. Isn't that a
bit too much handholding? I don't mind having an is_portable()
command or something similar, but it is incredibly annoying to have to
abide by someone else's filename restrictions.
I found a bug report at
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=776146&group_id=7586
and a discussion about this (though it focused more on "?" and "*") at
http://lists.boost.org/MailArchives/boost/msg46073.php
In particular, Beman Dawes said:
What is very explicitly not a supported use case is for providing
simply a new but still non-portable interface to non-portable
operating system API's. If that is the need, just call the
non-portable operating system API's directly.
If we were to take that to the extreme, then boost::filesystem should
only accept 8.3 filenames. What Beman seems to be missing is that he
has made an extremely nice interface to filesystems. It is much
simpler and easier to use within C++ than the non-portable API's. But
it is unneccesarily difficult to look at whatever files the user may
have created. This makes the library much less useful than it might
otherwise be.
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.
Thanks,
Walter Landry
[EMAIL PROTECTED]
--- /home/boo/arx/arx/src/boost/{arch}/++pristine-trees/unlocked/boost/boost--ar
x/boost--arx--1.0/[EMAIL PROTECTED]/boost--arx--1.0--patch-6/./libs/filesyst
em/src/path_posix_windows.cpp 2003-07-18 13:22:15.0 -0400
+++ /home/boo/arx/arx/src/boost/./libs/filesystem/src/path_posix_windows.cpp
2003-07-31 10:37:51.0 -0400
@@ -128,17 +128,6 @@
{
// error checking functions /
/
-
-bool generic_name( const std::string & name )
-{
- return name.size() != 0
-&& name.find_first_of( invalid_generic ) == std::string::npos
-&& name != "."
-&& name != ".."
-&& *name.begin() != ' '
-&& *(name.end()-1) != ' ';
-}
-
bool posix_name( const std::string & name )
{
return name.find_first_not_of( valid_posix ) == std::string::npos
@@ -308,13 +297,6 @@
# endif
);
- if ( context == generic && !generic_name( name ) )
- {
-boost::throw_exception( filesystem_error(
- "boost::filesystem::path",
- "invalid name \"" + name + "\" in path: \"" + src + "\"" ) );
- }
-
m_path += name;
}
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
