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: 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 \\?.

Best regards
Jorge