Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-04-21 09:38:47

At 09:15 AM 4/21/2003, Vladimir Prus wrote:
>Jason House wrote:
>> Vladimir Prus wrote:
>> > Does those "alternate streams" belong to filesystem library at all?
>> > For one thing, the ':' symbols is not allowed anywhere except for
>> > name. For another thing, on all systems but NTFS, "bar.baz.blip:blat"
>> > would be considered as having "blip:blat" extension, and making the
>> > function behave differently on NTFS is confusing. Lastly, the
>> > function is supposed to do only syntax transformation, but to tell if
>> > you're on Fat32 or NFTS you'd need to ask operating system...
>> >
>> > - Volodya
>> From the library standpoint, I would have to imagine that there should
>> be some kind of support for appending :blat...
>> In fact, you can even add a stream to a directory! c:\:hiddenfile.txt
>It's hard to portably support unportable extension ;-) In fact, a
>simple issue of finding file attributes (size, for example), is still not

>finally solved.
>> Without any real usage information, I find it hard to say what the
>> extrension truly is. Maybe blip:blat really would be appropriate. In
>> most cases it would make the file extension unrecognized through code
>> unaware of :blat... But it does make me wonder if there is some way to
>> make such a case more obvious to the application programmer... The
>> file usage example I've seen actually did stuff like good.txt:bad.txt
>> ... the used a new file extension in the stream name! At the very
>> least, this might break the "last period" rule for file extension...
>Alas, I can't add more to this discussion. I don't know a bit about how
>alternate streams are used, and don't have the time to find out.
>I think that basic, syntantic "extension" and "change_extension" are
>usefull anyway.
>Beman, if that's fine with you, I'll code them.

Yes, go ahead. Although the concept of "extension" may be foreign on some
operating systems, I think the idea is widespread enough to be worth
including. If I understand your proposal correctly, the code and its usage
will be portable when applied to a path build from the generic grammar and
the results will be more or less correct (if a bit odd) when applied to a
path which used the system dependent constructor and an operating system
specific path string.


Boost list run by bdawes at, gregod at, cpdaniel at, john at