On Wed, Oct 26, 2011 at 12:59 PM, Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote:
On 26.10.2011 12:24, Yakov Galka wrote:
[...] you still cannot use long paths on windows (longer than MAX_PATH), although they are supported by the OS. Moreover, judging by the last fixes to the library, it looks like Beman wants to shift the burden of this on the user of the library, instead of implementing something that works transparently.
[...] However the MAX_PATH issue is not really an issue in practice.
The *only* uses I have seen of paths longer than MAX_PATH, have been silly script-kiddies trying to create problems for people running FTP servers. And that's because the ordinary tools can't handle them, thus, difficult to remove the script-kiddie's nested folders. Conversely, as a serious software developer one should stay well away from such paths.
It's a big world out there Alf, and paths longer than MAX_PATH are routine in at least one commercial here I know with Unix / Linux roots that's been working fine for years, and that's creating issues for its Windows port ATM, since indeed many Windows APIs are MAX_PATH limited (despite the weird filename handling to support MAX_PATH), and many scripting engines (e.g. TCL) are thus limited (those are used as utilities to manage the app's file-based "databases"). I'm not saying Boost.Filesystem *must* transparently support long paths, although that'd be terrific, but I'm pointing out that your assumption that long paths are only used by "silly" teenagers is a bit narrow minded. --DD