Main Area and Open Discussion > Living Room

Query re FIND [..foldername] problem in Locate32 (and Windows Explorer)

(1/1)

IainB:
I have been trialling Locate32 (latest 64-bit version) for a while, and yesterday I was puzzled because some files that I had just created and that would have been indexed by Locate32 in its latest database update were not showing up in Locate32's results page. At the same time I got an error - which was not repeatable.

I wrote to the developer of Locate32 per email:
​I was using Locate32 and searching for files/folders named ..Audio
After sorting the results list, I got this error message:
CLocateDlg::SortNewItem:Something is wrong! Contact jmhuttun@{redacted}
I have established that Locate32 seems to be unable to catalogue/index folders with a preceding dot (.) or preceding two dots (..) in the folder name, and it cannot seem to catalogue/index the files within such folders either.
System is Win7-64 Home Premium.

--- End quote ---

He replied:
​Looks like that you are trying to something strange. I should recommend not using '.', because it's meaning is quite vague in GUI programs.

--- End quote ---

However, I see nothing strange about it. Windows File System allows for preceding 1 or more full stops in file/folder names and quite a lot of programs use at least 1 preceding full stop in file-naming - e.g. Google Picasa. I have been using folder names with preceding dot(s) (.) for years with no issue until now - and my File Manager is xplorer² (I rarely - if ever - need to use Windows Explorer).

This is an example of a typical filename and path that seems to be causing difficulty for Locate32:
C:\Workdata.007 (Media 1)\..Audio\Personal + Family\2012-01-31 224456 - Meeting notes at Labour MP office (9m 48s).amr

Puzzled, I did a comparison, using different tools to do the searching:

* 1. Using the FIND command for files/folders in Windows Explorer and also using Regex ".*.*" or "..*.*" seems to indicate that it is partially blind. That is, it:
(a) can find non-specific folders with preceding full stops (1 or 2) with no problem, but
(b) cannot find a specific ..foldername or specific filename.ext within that ..foldername, but
(c) can find files with specific .ext but a non-specific filename within those folders;
(d) can find a specific or non-specific foldername within those folders.


* 2. Using Locate32, it cannot seem to find those specific ..foldername folders, nor non-specific ones, and cannot find any files - specific or non-specific - within those ..foldername folders. It seems to be "blind" to the ..foldername and any files/folders nested within it.


* 3. Using FIND in xplorer², it can find specific and non-specific ..foldername folders and any files/folders (specific or non-specific) nested within them, with no difficulty.
Q1: Am I doing something wrong here, or have I tripped over some kind of a bug in Windows and Locate32?

I rather like Locate32 because it is fast, but if it fails to actually catalogue certain undefined and apparently legitimate types of file/folder names in NTFS without your knowledge, then I shall have to use an alternative, or go back to using xplorer² (which, though it seems to be fail-proof in this context, is slower, as it does a real-time search the first time you search for something). If I can possibly avoid it, I certainly don't want to have to change my long-established folder-naming conventions to accommodate Locate32.

Q2. What alternatives are there to Locate32 that would not have this ..foldername problem?

(Thanks in anticipation.)

4wd:
Everything seems to handle .xxx and ..xxx OK, listing those folders and whatever is in them.





I'm using the latest beta which has yet to give any problems on my machines.

IainB:
@4wd: Many thanks for taking the trouble to test that out for me to prove it on Everything.
I have uninstalled Locate32 and downloaded and installed Everything-1.3.3.658b.x64.exe. It's very fast. Works a treat.

4wd:
If it's searches you do often, you may want to check out Everything's bookmark feature and set one up for that particular search.

eg.

Entering apf: (Audio Personal Family) would limit to specific folder, filetype and sort method.

You could then enter apf: meet to get any file in a particular folder, of a particular type with meet in the name.

IainB:
^^ Thanks for the tips. I shall have to start learning about Everything's feature set now, and how best to use those features.

Meanwhile, a remaining issue seems to be the curious conditional "blindness" bug that I had tripped over that is displayed when using Windows Find and Locate32 - a bug that xplorer² and Everything do not display.
I would have thought that the Windows OS Search/Find would be certain to be able to find any and every filename in NTFS that it had let you create, but apparently not, even in Win7-64.     :tellme:

Navigation

[0] Message Index