>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 root
>> > 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
>'extension'
>> > 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 seemingly
>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 only
>> 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 quite
>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.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
