[boost] Re: Re: [filesystem] Generic path grammar corner cases

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-06-02 13:54:56

"Jonathan Wakely" <cow_at_[hidden]> wrote in message 
news:20050602175118.GA34709_at_compsoc.man.ac.uk...
> On Thu, Jun 02, 2005 at 10:37:14AM -0400, Beman Dawes wrote:
>
>>
>> "David Daeschler" <daveregs_at_[hidden]> wrote in message
>> news:d7n1to$rr7$1_at_sea.gmane.org...
>> > Since the slash or slashes in that case are extraneous, I would also 
>> > say
>> > option 2 is the way to go.  Remove the trailing slash because it was
>> > probably not intended in the first place.
>>
>> I don't believe removing a trailing slash is a good idea because that 
>> isn't
>> how POSIX or Windows treats a trailing slash, and  also because some apps
>> may depend on it to distinguish between a directory path and a file path.
>
> e.g a trailing slash changes semantics when dealing with symlinks:
>
> $ mkdir aaa
> $ touch aaa/monkey
> $ ln -s aaa bbb
> $ ls -l bbb
> lrwxrwxrwx  1 redi redi 3 Jun  2 18:40 bbb -> aaa
> $ ls -l bbb/
> -rw-rw-r--  1 redi redi 0 Jun  2 18:40 monkey

Interesting.

> In answer to your first question, I think I prefer (2) too.
>
> Regarding the escape sequence, do you want to play nicely with
> null-terminated char strings?  If not, '\0' would be my choice, since
> that and '/' are the only characters POSIX disallows in a filename.
> But there are probably plenty of ways that would cause otherwise valid
> programs to fail.

Yep, I thought of that too. But since we do want to be able to "play nicely 
with null-terminated char strings", I think it's a non-starter.

> Then again, I'm not sure it's necessary to support slashes in filenames
> at all.

I don't think it is strictly necessary for the Boost implementation, either. 
But I want to propose Boost.Filesystem for standardization, and need to know 
what the spec would be for, say OpenVMS. And allowing them does cover the 
admittedly obscure case of someone who just has to create a path "foo//bar", 
which they would do via path("foo/\abar"). It is a bit of a kludge, but 
since the expected usage is very uncommon, I don't see that as a problem. 
The impact on both specification and implementation is trivial.

Thanks,

--Beman