Subject: Re: [boost] Making Boost.Filesystem work with GENERAL filenames with g++ in Windows (a solution)
From: Jorge Lodos Vigil (lodos_at_[hidden])
Date: 2011-10-26 10:24:11
Alf P. Steinbach wrote:
>>> 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
These are other uses I have seen:
1. Malware authors giving malware long names
2. Long path created within VS database projects as a consequence of large index or key names
3. Long paths created as a consequence of moving a folder structure to a new destination with a larger path
4. Malware collections with sha1 hashes as filenames organized in folders with partial hashes as folder names
>>> 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.
I believe the situation is quite the contrary. As a serious software developer you should be aware that long paths are possible and make your software compatible with them. On the worst case make it fail gracefully. I agree that you should try to avoid _creating_ long paths, precisely because other software developers chose not to support them in their applications.
> You don't need such long paths for any size of data.
I don't agree with this. Of course, that depends on your definitions of "need". But there are times where long paths are very convenient.
> Those long paths can't be handled by Windows Explorer or most other
> software. Therefore, adding an ability to use them inadvertently, is at
The ability is not added, it is already there. You can create long path with Explorer. For instance, share a folder with 200 character path, map it to a network disk and copy to the mapped device a folder structure with paths larger than 60 characters. Other possibility is moving (rather than copying) folder structures within another large folder. It is _your_ software that needs to handle these cases gracefully. The Explorer problems must not prevent you to solve similar problems in your software.
> best strongly misguided. It would encourage novice developers to create
> files that ordinary users can't delete, move or rename.
I agree with this, but it applies only to _creation_. You should be able to handle long paths created by others.
> 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
I believe this is wrong, examples were provided above.
> creates trouble for the users. Don't even think about it -- and here
> I'm not talking about Boost, but about your own efforts.
I believe it would be nice if boost::filesystem supported long paths in Windows. In fact, to a great extent it already does. What I think would be needed is tests with filenames starting with \\?.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk