Re: [boost] Re: [filesystem] new functions proposals
At 03:21 AM 4/25/2003, Vladimir Prus wrote: Beman Dawes wrote: 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. Yes, I think that's so. I attach a patch against CVS HEAD with implementation, docs and tests. Could you take a look and tell if anything should be corrected? * There are two places in the docs where what should be shown as '.' is showing up as apos;.apos; (browser is IE 6). * empty() is misspelled as empy() in several places. But see next item. * I think the preconditions should be removed. In each case, the behavior as specified is quite sensible even if ph.leaf().empty(), and may be useful in some applications. (Assuming you agree, the assert()'s should be removed, and test cases should be added.) * You have my permission to remove my copyright from the docs and add your own. You've contributed all the pieces, so no need to mention me. * Please add Contributed by Vladimir Prus. to each function. I'd like to track all contributors. * Go ahead and commit to CVS. Then let's keep an eye on the test results for a couple of days as the changes get tested on various platforms. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [filesystem] new functions proposals
At 12:14 AM 4/27/2003, Trevor Taylor wrote: So it sounds to me like the :blat is *not* part of the extension. It sounds like the NT file name is made up of three parts: name, extension and stream. In which case I think it is fine to have functions extension() and change_extension() - they just should not report or modify the stream part. To implement them I guess I'd need to know whether the file name was an NTFS filename, and then how to reliably locate the extension part? Just my 2 cents... Many legacy filesystems append version or similar identification to file names, often using ':' as a delimiter. OTOH, ':' is a valid character in a file name (and in an extension) on many operating systems. Trying to distinguish between those two cases on an operating system by operating system basis just doesn't seem possible. Better to only promise what we are sure can be delivered - in other words, Vladimir's suggested semantics. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [filesystem] new functions proposals
At 10:08 AM 4/27/2003, Pavel Vozenilek wrote: Trevor Taylor [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] So it sounds to me like the :blat is *not* part of the extension. It sounds like the NT file name is made up of three parts: name, extension and stream. In which case I think it is fine to have functions extension() and change_extension() - they just should not report or modify the stream part. To implement them I guess I'd need to know whether the file name was an NTFS filename, and then how to reliably locate the extension part? Functin DeviceIoControl() with parameter IOCTL_DISK_GET_PARTITION_INFO can do it. It is available on NT/W2K. Does it make sense to take into account NTFS drives for Win95/98 (from www.systeminternals.com) or Linux NTFS drivers? There are a lot of file systems in this world. It isn't uncommon for the heavy-duty operating systems to handle many different path formats. IIRC, OS/390 (and C++ compilers for it) handles six different path formats. The purely lexical approach taken in Vladimir's proposal is a practical way to meet a common need in portable C++ programs. Let's just leave it at that, and not worry that it won't handle certain non-portable path formats. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
Trevor Taylor [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] So it sounds to me like the :blat is *not* part of the extension. It sounds like the NT file name is made up of three parts: name, extension and stream. In which case I think it is fine to have functions extension() and change_extension() - they just should not report or modify the stream part. To implement them I guess I'd need to know whether the file name was an NTFS filename, and then how to reliably locate the extension part? Functin DeviceIoControl() with parameter IOCTL_DISK_GET_PARTITION_INFO can do it. It is available on NT/W2K. Does it make sense to take into account NTFS drives for Win95/98 (from www.systeminternals.com) or Linux NTFS drivers? /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
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 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... ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [filesystem] new functions proposals
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 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
James Curran wrote: Vladimir Prus wrote: The intent is to get/change the part of leaf name after the first dot. um.. After the FIRST dot or the LAST dot. In Win32, james.m.curran.txt the extention is txt, not m.curran.txt Certainly the last. My existing code uses the last dot, in fast, and I've just typed wrong. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
Jason House wrote: James Curran wrote: Vladimir Prus wrote: The intent is to get/change the part of leaf name after the first dot. um.. After the FIRST dot or the LAST dot. In Win32, james.m.curran.txt the extention is txt, not m.curran.txt Note too that on Windows/NTFS, names like 'c:/foo/bar.baz.blip:blat' are legal. The 'extension' is '.blip', not '.baz.blip' and not '.baz.blip:blat'. :blat ??? 1. I have no clue what that would mean I, too, had not clue about this until now. 2. Is there any handling of :blat in any way shape or form in the file system stuff? I don't remember seeing any description of that case... 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 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
James Curran wrote: Vladimir Prus wrote: The intent is to get/change the part of leaf name after the first dot. um.. After the FIRST dot or the LAST dot. In Win32, james.m.curran.txt the extention is txt, not m.curran.txt Note too that on Windows/NTFS, names like 'c:/foo/bar.baz.blip:blat' are legal. The 'extension' is '.blip', not '.baz.blip' and not '.baz.blip:blat'. The very existence of such special cases probably means that such a function would be a good addition to the filesystem library. -cd ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
:blat ??? 1. I have no clue what that would mean 2. Is there any handling of :blat in any way shape or form in the file system stuff? I don't remember seeing any description of that case... Carl Daniel wrote: James Curran wrote: Vladimir Prus wrote: The intent is to get/change the part of leaf name after the first dot. um.. After the FIRST dot or the LAST dot. In Win32, james.m.curran.txt the extention is txt, not m.curran.txt Note too that on Windows/NTFS, names like 'c:/foo/bar.baz.blip:blat' are legal. The 'extension' is '.blip', not '.baz.blip' and not '.baz.blip:blat'. The very existence of such special cases probably means that such a function would be a good addition to the filesystem library. -cd ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
Jason House [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] :blat ??? 1. I have no clue what that would mean 2. Is there any handling of :blat in any way shape or form in the file system stuff? I don't remember seeing any description of that case... It means alternate stream of NTFS file. One file can contain any number of such streams. Default one - unnamed - is what you usually use. To use alternate stream, just append :something to the filename parameter of an API call. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
