[boost] Re: Handling unix-characters with boost::filesystem (bug 776146)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-07-24 00:27:38

Hi Erkki,

Erkki Seppala wrote:

> Source-code of a utility to remove those files from directory2 that
> exist in directory1. It fails if any filename in directory1 contains a
> ':' (and I expect it'll fail with numerous other characters too):

[...]

>     for (fs::directory_iterator it(base);
>          it != end;
>          ++it) {
>       std::cout << "Removing " << it->leaf() << std::endl;
>       fs::remove(*it);
>       fs::remove(base2 / it->leaf());

[...]

> testing: mkdir foo bar; touch foo/a foo/: bar/a bar/: bar/c; ./baz foo bar
> 
> As this behavior (handling certain characters differently on systems
> that can handle them) seems to be a designed feature, I must raise my
> concern that I really don't want to see a generation of unix-programs
> that fail to handle some files I have in my hd. The program above
> would seem to me to be perfectly portable even if had the ability to
> handle all kinds of characters in filenames. (I wouldn't want to
> resort to using some depreciated native-interfaces to accomplish that
> either.)

I tend to believe that you've found a bug in filesystem library. It's
possible to take native path with ":" as last component. It possible to
extract that last component. But path::leaf returns string, so

   base2 / it->leaf()

expression tries to convert ":" into path, and fails. It seems to be that
one I've converted native path into "path" instance, it should not complain
about disallowed characters. The above example works if I write

  base2 / fs::path(it->leaf(), fs::native)

but this does not look like a solution... The real solution, IMO, would be
to make "leaf()" return "path" instance, but I don't know the rationale for
making it return string, so maybe this idea is not good. Beman, could you
comment?

> And answering to Vladimir Prus on the bug report: I would hate to see
> a program that was not able to create, manipulate and unlink certain
> files, just for the sake that some other platforms have problems with
> those characters. Handling files called ' ', '"*?' isn't a problem for
> me. I have almost a 1000 files with character : (perl manual-pages)
> and some with letters < and >.. (think message-id's)

I don't think anybody will be happy with prohibiting to work on files with
special characters. It's only required to pass fs::native when you create a
path from external path name which can include system-specific characters.

> (Btw, why is this a library-issue at all anyway? I'm sure the
> operating system is more than pleased to tell the program that the
> filename is invalid.)

Sometimes so, sometimes not. Imagine you pass a filename to "system" call,
something like

  system("foobar " + file.native_file_string())

Ok, and "file" is "somefile && rm -rf /". So this will wipe your entire
harddrive. You need to to some checks, naturally. With the current design,
you only have to do the checks when you accept input from external sources,
i.e. when you pass fs::native to ctor. If no checking for special symbols
is done, you have to examine all places where path objects are created.

Until now, I was not too troubled by fs::native. I usually create paths from
native strings in a few places and then manupulate the resulting paths.

- Volodya