Re: [boost] Making Boost.Filesystem work with GENERAL filenames with g++ in Windows (a solution)

Subject: Re: [boost] Making Boost.Filesystem work with GENERAL filenames with g++ in Windows (a solution)
From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2011-10-26 09:27:39

On Wed, Oct 26, 2011 at 12:59 PM, Alf P. Steinbach
<alf.p.steinbach+usenet_at_[hidden]> 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