Beman Dawes <bdawes@acm.org> wrote:
At 11:25 PM 9/26/2004, Walter Landry wrote:
Greetings,
I have come across an annoying problem with the filesystem library. I have wrapped filesystem with Swig so that I can call it from python. I had to rewrite the filesystem::path implementation a little because Swig can't handle nested classes. In any case, once I got that sorted out, I wanted to do something like
p=path(".bar")
which doesn't work because filenames starting with a period are not allowed by the default name checking routine. Argh.
Unfortunately, I can't figure out how to change the default name checker from python. If I worked at it long enough, I could probably work it out. But I am sure that I don't want to have to run something like path.default_name_check(no_check) at the beginning of every 10 line script. It is a particular piece of functionality (name checking) that just gets in the way. I would wager that most people using boost::filesystem from scripts would not want to have to deal with it, since it is completely different from every other portable, cross platform filesystem API.
So to make a long story short, I think the default for boost::filesystem should be not to check for "portable" paths. This is different from a position I took earlier, where I thought that it is ok if I only have to set it once at the beginning. That is acceptable for large programs, but not for small ones.
Peter Dimov and others have also argued that the default is wrong, and I'm sympathetic to their arguments. Some people may believe the default should be "native" rather "no_check".
If I so desired, I could mount HFS+, BeFS, JFS, FFS, BFS, ADFS, FAT, VFAT, NTFS, ext2/3, XFS, UMSDOS, Reiserfs, ISO 9660, and UDF on my machine. Which one is "native"? If the intent is make sure that all paths can actually be accessed on the machine, then you don't need to do any checks. The operating system does that for you. If you are not actually opening files, then perhaps you don't need this check anyway? Besides, doing any checking implies a (perhaps mild) performance hit, and I don't want to have to jump through hoops to get rid of something I don't need.
Either of those would be breaking changes for some current programs which use the library, and we would have to figure a way to deal with that.
A compile-time option? Users who want the old behavior can compile with BOOST_FILESYSTEM_PORTABLE_DEFAULT defined. Regards, Walter Landry wlandry@ucsd.edu