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
>> 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
>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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk