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