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: Alf P. Steinbach (alf.p.steinbach+usenet_at_[hidden])
Date: 2011-10-26 09:47:27

On 26.10.2011 15:27, Dominique Devienne wrote:
> 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.

In Windows. Don't lose that context.

In a system that fully supports feature X, feature X can be reasonably 
used even if it's of no particular benefit.

In a system where use of feature X creates trouble, and where 26 years 
of worldwide experience says that it's not necessary, it's not a good 
idea to encourage its use.

Cheers & hth.,

- Alf