Re: [boost] Re: [filesystem] new functions proposals

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 
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