"WARNING - cannot open" during multi-file search

[Aeneas]

I just installed version 7 on Windows 7 64 and noticed this new error "WARNING - cannot open" during large searches.
I received the same number of results as with version 5,
so I assume this is a problem perhaps in the Windows kernel.
Is the limitation 256 bytes of pathname, and is there any workaround to allow it to search very long pathnames ?

When a text editor fails to find a match in a multi-file search,
that is a serious failure of the program, and the developers
should do everything possible to rectify such a bug.

[jschwartz13@att.net]

I am getting this error for it looks like every file that was searched in the folder that was chosen to search.

C:\Users\jschw\OneDrive\Documents\~word documents\sleep images.docx: WARNING - cannot open

textpad 8.22.1

[bbadmin]

Docx files are not plain text, so TextPad is unlikely to find text strings in them. However, that should not prevent it from opening them. MS Word keeps locked any files it has open, so could that be the cause?

is there any workaround to allow it to search very long pathnames ?

Symbolic links can be used to create a shorter path to files. This article explains how to create them:

https://www.tenforums.com/tutorials/131 ... ndows.html

[AmigoJack]

is there any workaround to allow it to search very long pathnames ?

Symbolic links can be used to create a shorter path to files

Actually programs can work with up to 32.767 character long paths/filenames for decades already: one has to use the "Wide" version of a Win32 API function (f.e. FindFirstFileW()) and then prepend paths/filenames with a 4 character prefix:

By default, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, prepend "\\?\" to the path.

I'm using this for decades in my programs and never had any problems with it. Unlike Windows' File Explorer, which isn't able to go beyond MAX_PATH (260) characters, too. Which is a terrible restriction on what NTFS is capable of.

[bbadmin]

The problem is that TextPad uses Windows Explorer for its Open File dialog box, so internally it uses the same MAX_PATH character limitation.

[AmigoJack]

Open File dialog

That

• is virtually the only bottleneck/edge case - one could still open files in many other ways where no MAX_PATH limit is imposed:
  • program parameter,
  • drag'n'drop from anywhere (not just Explorer),
  • using short filenames on every folder and the filename itself to cut down character count...
• has nothing to do with the issue here - when recursively searching for/in files the starting directory may still be within the MAX_PATH limit, but files beyond that may exceed 260 characters in full. But when searching in files the "open" dialog is not even involved - neither when TextPad would read a file, nor when the user double clicks/presses ENTER on a match in the search results.

Yes, the "open" dialog is lousy (since it's just an Explorer itself), but that's more or less the only spot you couldn't change. Isn't that the point of "search in files": to not open every one through the dialog window?

[bbadmin]

TextPad uses a Microsoft API that passes filenames around in arrays of size MAX_PATH and explicitly rejects any that are longer to prevent buffer overflows. Find in Files has no such limitation but is stymied by that API.

I understand the frustration, but as this thread was started in 2014, and only one person has complained here since, it can't be affecting many users. (You actually have to manually set a value in the registry before you can use long file names, and then they have to be prefixed with "\\?\" for some bizarre reason.) However, now that it's been brought to our attention again, we'll investigate solutions.

[AmigoJack]

(You actually have to manually set a value in the registry before you can use long file names

No: this is only possible since some version of Windows 10 or younger. Older systems don't even have that Registry setting available.

But it can still easily happen to have a path that is just about below the MAX_PATH limit and then move either

• files with long filenames or
• whole folders with sub folders

into that path to effectively get files which you can't reach with the Explorer (or most other programs) anymore. This is possible since Windows 2000 already (or even NT4) and can happen to anyone, unbound to any Registry setting. One then has to either use software like FreeCommander which supports 32.000 character long paths, or use the 8.3 short filename of each folder and the file's name to hopefully stay below the MAX_PATH limit in sum. Trust me - I did this for decades.

they have to be prefixed with "\\?\" for some bizarre reason

Which is only possible for all the "Wide" versions of the API functions. The reason is not that bizarre, because the Native API functions (not available to the programmer in normal ways) which are then used by the WinAPI itself have this filename syntax by default and it also evades any automatic Explorer-like modifications to the given filename (such as casing and not allowing trailing dots).

If you want, I can give you a small self-compiled program that creates such unreachable folders/files for you, and being able to browse all files beyond the MAX_PATH limit easily (to then delete such files/folders again). It then is also able to create files with names that wouldn't be allowed in all the Explorer-limited ways, too (like having leading spaces in a filename).

Thanks for considering this for future TextPad versions.

[bbadmin]

You've made a great case for using Linux!

[IanOfYork]

You can also reduce path lengths by creating a "drive" for your files.

Include the following in the startup script:

Code: Select all

subst J: C:\Users\jschw\OneDrive\Documents

That way, long file paths such as:

Code: Select all

C:\Users\jschw\OneDrive\Documents\~word documents\sleep images.docx

become much shorter:

Code: Select all

J:\~word documents\sleep images.docx

This also has the advantage of isolating your scripts and utilities from needing to be changed when you evolve from using OneDrive to some other cloud storage system or adopt a local external drive for your files.

[AmigoJack]

One could also create junction/reparse points which are permanent to the file system and don't need a spare drive letter. But it's a shotgun workaround, too (just like a substitution drive), since you need to know beforehand where paths get too long.