| Pi |
|
Allergic to life
|
|
|
|
|
Reged: 09/20/03
|
|
Posts: 6449
|
|
Loc: Room 101
|
|
|
|
Send PM
|
|
|
|
Before anything, let me state that I already use a third party renaming utility, in my case the excellent BRU which is free and powerful (http://www.bulkrenameutility.co.uk/).
However not all times I launch BRU for some simple search/rename of one or two files hidden in a folder containing thousands of other files. I just type the search in Windows Explorer (Windows 7) and rename the offending files directly in the search results.
When you're renaming a file in Windows Explorer, it takes care that the whole file including drive and path doesn't exceed MAX_PATH, which AFAIK is 260 characters in all modern Windows. So it doesn't let you edit the name past that limit. Trying to do so rewards you with a beep, warning you that you're at the maximum in that edit box.
However, when you try to rename any file in a search result in Windows Explorer, it doesn't work that way. First of all, the limit is only 128 characters for the filename, and second, it doesn't care about the path. So if you have a filename of 150 characters located in "C:\Foobar", you should still have 100 characters more to edit it, but in the search result, you would actually have to shorten it before you're allowed to change anything else. Delete chars, yes. Backspace works. But can't type anything until you've mutilated the filename enough for this stupid limit.
I don't know why it has to be different. Windows Explorer, renaming. Maybe the renaming code is different in the search result view, and it has some sloppy code put in place until Win10. Moreover, searching Google for this problem is in itself a problem. All the results I find deal with long filenames (>MAX_PATH) and how to locate/rename/move/make them work.
It's damn annoying to meet the damn limit in the damn middle of damn editing. KILL-RUSH.
[ATTACHED IMAGE]
|
Wound up, can't sleep, can't do anything right, little honey / Oh, since I set my eyes on you. / I tell you the truth.
I can't get it right / Get it right / Since I met you...
|
|
|
Re: Windows 7 searches annoying limit for long filenames
[Re: Pi]
#331513 - 09/09/14 02:14 PM
|
|
|
The whole MAX_PATH thing is infuriating. Because some applications depend on getting an error from APIs if a longer path is supplied, the ANSI APIs always return an error when attempting to use a path longer than this limit. The wide character APIs return an error unless you prefix the path with \\?\ in which case they will work with longer paths. You have to be really careful to remember this whenever dealing with paths or you'll end up not consistently working with paths longer than MAX_PATH. As you've discovered, Microsoft's own applications aren't great at supporting long paths. Particularly frustrating is the fact that .NET intentionally doesn't support long paths.
|
|
|
|
Re: Windows 7 searches annoying limit for long filenames
[Re: Vas Crabb]
#331637 - 09/12/14 02:33 AM
|
|
|
> As you've discovered, Microsoft's own applications aren't great at supporting long paths.
I always wondered why, even in XP, it would say 'the name of this file is too long for the recycle bin' when deleting some bookmarks.
|
Scifi frauds. SF illuminates.
_________________
Culture General Contact Unit (Eccentric)
|
|
|
Index 
Threaded 
Windows 7 searches annoying limit for long filenames
Reply
[Re: 