|
Boost : |
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:05:51
On 26.10.2011 14:17, Yakov Galka wrote:
[snip argumentative noise]
> On Wed, Oct 26, 2011 at 12:59, Alf P. Steinbach<
>>
>> 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.
>
>
> This offends me. I'm facing the MAX_PATH limitation at my work. If you
> develop nothing more than desktop apps that interact directly with the user,
> then please don't infer from this that others don't need it either. MAX_PATH
> is a problem in a large scale systems where you have enormous amounts of
> data.
You don't need such long paths for any size of data.
> In particular this is why we don't switch to boost::filesystem (since
> it neither workarounds the problem nor works well when given a long path
> with \\?\).
Those long paths can't be handled by Windows Explorer or most other
software. Therefore, adding an ability to use them inadvertently, is at
best strongly misguided. It would encourage novice developers to create
files that ordinary users can't delete, move or rename.
The world has 26 years of Windows usage without such long paths, even
after they were introduced in 1993.
So with 26 years of not needing them going on strong, and 18 years of
not being used (by anyone other than script kiddies) despite being
there, it is an established fact any competent developer don't need them
and won't use them. And also, it is an established fact that using them
creates trouble for the users. Don't even think about it -- and here
I'm not talking about Boost, but about your own efforts.
Cheers & hth.,
- Alf
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk