PDA

View Full Version : OT: Is win7 search really THAT useless?



J Tiers
09-27-2015, 10:54 AM
Some snafu with a backup system caused a LOT of directories in my data files to have files duplicated. Most have been named <filename.ext.1>, where the ".1" is the duplicate file, and same file exists without the ".1".

This has happened before, but was on XP, and I simply searched for them and deleted them wholesale. Worked fine, and the backup would get sorted out OK

Si I assumed that with Win 7 the system would be similar. NOT SO, apparently.

I can look directly at the files in a directory, search for them, and have the search come up "no files match". This is insane. I can SEE them, and it says they are not there. Looks like that old warehouse cartoon where the computer says they are out of what they are looking at a bin of.

I am pretty sure I have the search set to show hidden files, etc. The regular directory view definitely is. I suppose a ".1" file might be deemed to be a system file.

Going through and manually finding and deleting each individual file is not going to be practical. And they have to be deleted, since they are taking up storage space. I once had this end up with .1, .1.1, and some .1.1.1 files. It can happen if the log file gets fouled up on any of the various computers that I am keeping synched.

Because I do NOT use the setting that performs deletions as well as additions, it will not propagate deletions, and they have to be made on each plus on the transfer medium, which is fine. That's preferable to losing huge swaths of data by accident.


EDIT:

I noticed that it is NOT ".1", it is ". 1" with a space. That makes it 20 times worse, because the worthless search NOW shows up any name that has a space and a 1, many of which I need to keep. So it is STILL ca case of having to manually search through 30 gb of files, to find each individual instance of a duplicate file and then perform several clicks to delete it.

Better living through computers................

brian Rupnow
09-27-2015, 11:21 AM
I run win 7 on my computer, and find it useless. ---Brian

J Tiers
09-27-2015, 11:31 AM
7 is fine, It's required by software anyway, so....... But the search is so crippled and dumbed-down as to be worthless.

It finds everything that has a '1" in it, despite being given *. 1 as the search string. Same with *. 1.*

Using *1.* finds everything that ends in "1", many of which I do not want to delete, and they are all mixed up together, requiring individual selection and clickety-click. Over several gb of files, this is not remotely practical.

When it is considered that I need to do this on several different computers, AND some stick memories, it becomes considerably worse. MS screwed the pooch, and no mistake. NO I CANNOT USE LINUX so don't bother mentioning it.

I specifically disabled "show partial matches", but I have found that MS sets stuff like that back to defaults every so often. Setting it explicitly does NOT change behavior. Then also, it likes to put a box around the identified item , in this case the "1". This makes it impossible to see if it is a ". 1" or just a "1". The box covers the dot location.

Was Microsoft really intending to make it impossible to use this feature effectively? It would appear so.

RichR
09-27-2015, 01:24 PM
See if this works:

*.*.?1

J Tiers
09-27-2015, 02:49 PM
No, with that, or variants of it, none of the target files show up, but lots of others do, or a mix shows up, etc.

It is the space before the "1" that is considered important by the file system, but is ignored by search. That is what fouls up everything.

All I can figure at the moment is to copy the entire 64 gb on a stick, take it to an XP computer, do the search and deletes, then copy it back in place of the original on the win 7 machine.

dp
09-27-2015, 03:54 PM
If you're doing this from a terminal session you have to put quotes around the file name. Or better yet install a POSIX subsystem and avoid Windows problems.

J Tiers
09-27-2015, 04:07 PM
No, I am using the regular windows 7 search facility.

It ignores the space the file system puts into the name. That's the issue.

It cannot tell the difference between "bracket 128541.PRT" and "bracket 128541. 1.PRT". BUT THE FILE SYSTEM KNOWS THAT DIFFERENCE.

Therefore it lists them all in the search results, forcing one to either slog through gigabytes one file at a time, reading, evaluating and clicking several times to delete each one, OR just sorting by size and forgetting about little ones, OR letting windows eat up disk space with thousands of un-needed duplicate files.

OR maybe copying to a stick, using XP to clear off the duplicate files, and copying the remainders back to the wiped directory.

Could Microsoft have made this ANY more difficult than they already deliberately and intentionally made it?

Barrington
09-27-2015, 04:23 PM
The following should find all files with a 'dot, space, one' extension:-

ext:". 1"

(It will also find 'dot, space, space, one' etc. extensions - it's just looking for white space rather than a single space character.)

Cheers

.

J Tiers
09-27-2015, 04:28 PM
Barrington: I am not using the command prompt.

And I should not have to.

Barrington
09-27-2015, 04:29 PM
Not a command prompt - just type it in the search box !

Cheers

.

(Google "Advanced Query Syntax")

J Tiers
09-27-2015, 04:37 PM
No items match that search.....

Remember, they don't put the . 1 AFTER the extension, they do it as a PREFIX.

Needs to find this type "PI chip layout. 1.JPG" and reject this type "PI chip layout.JPG", only the final extension may be, and is, anything at all...... JPG, AD_PRT, CIR, prm, DWG, bip, whatever. So I would have to separately search for each individual file type, and also for any that have ". 1. 1. 1" etc. And there are some like that also.

I don't know why they cannot just find what I want with a *. 1.* search string. That would make it simple. It's as if they did NOT want anyone fixing problems.... supposed to get Win 10, I guess.

Barrington
09-27-2015, 05:34 PM
Most have been named <filename.ext.1>, where the ".1" is the duplicate file, and same file exists without the ".1".



Remember, they don't put the . 1 AFTER the extension, they do it as a PREFIX.

Scratches head....:confused:


Anyway, then I think this is what you need:-


name:~ "* 1.*"


Cheers

.

J Tiers
09-27-2015, 06:31 PM
That didn't seem to do the job when I tried it. The search seems to delete all spaces when searching.

"scratches head" is right..... I want to make holes in the head of whoever thought this was a good idea.

The space, 1, dot is put in by the OS, and an OS function cannot handle it? Microsoft messed up bigtime if that is the case.... although that sort of messup by Microsoft is not exactly big news.....

I wonder how thoroughly they have been hacked by the chinese? They will probably never admit it, but my guess is they have been well and truly plundered. That's a Microsoft level of fail.

Mike Amick
09-27-2015, 08:06 PM
Jezz .. get upset already ...

Just use this

System.FileName:~=". 1.

Just like that

J Tiers
09-27-2015, 08:15 PM
If you meant that whole line, "no items match your search".

Ditto for all reasonable permutations

Mike Amick
09-27-2015, 08:20 PM
Jerry .. not sure if you are talking to me or not .. but .. my method works ..

cut and past that whole thing ... including the System.File part

it works.

J Tiers
09-27-2015, 08:36 PM
Jerry .. not sure if you are talking to me or not .. but .. my method works ..

cut and past that whole thing ... including the System.File part

it works.

Mebbe it works for you.

It does NOT work here, Win 7 pro, SP1. All I get from it is "no items match your search".

And I KNOW FOR A FACT that there are files present with that sequence in them, I just searched with a different search and found them, all mixed in with any other files having a "1" in the name..... spaces and dots are not important to search, apparently. Not in Win 7.

Mike Amick
09-27-2015, 08:49 PM
thats interesting ... I created two files.

Yeti.txt
Yeti. 1.txt

All the variances you tried I came up with the same results.

The solution I finally came up with works perfect for me .. .

Could someone else maybe try this ?

Actually cut and paste this whole line

System.FileName:~=". 1.

J Tiers
09-27-2015, 09:10 PM
Actually cut and paste this whole line

System.FileName:~=". 1.

That is what I did

Interestingly, it does not work in XP, AND XP does not correctly find the dot, space, 1,dot sequence either. So that isn't going to help any.

Nothing specifically found the yeti. 1.txt in either system.

Mike Nash
09-27-2015, 09:21 PM
I haven't tried this Windows 7 search yet. Looks right terrible though. For anyone else looking I did find this :

http://syncor.blogspot.com/2012/02/searching-by-filename-only-in-windows-7.html

which does mention Mike Amick's search terms. Pretty bizarre, but then again, everything has become counter-intuitive these days. We only thought MSDOS command lines were bad. (OK, I admit, I used Xtree Gold.)

J Tiers
09-27-2015, 09:57 PM
Apparently from folks comments on that page, it doesn't always help. As in my case....

It comes from here:

http://windows.microsoft.com/en-us/windows7/advanced-tips-for-searching-in-windows

I notice that their options do change, since I am offered NONE of the filter options they suggest may be available. They DO state that the options change depending on what "library" you are in, and I am in NO "library", but just searching in my data directory. I long ago standardized on a data directory name, and it is NOT "my documents", or any such microsoft suggested noise....

caveBob
09-27-2015, 11:38 PM
Everything Search Engine
http://www.voidtools.com/


UltraSearch
https://www.jam-software.com/ultrasearch/


TreeSize Personal for duplicates
http://www.jam-software.com/treesize_personal/


or


xplorer˛
http://zabkat.com/

J Tiers
09-27-2015, 11:46 PM
Well, I located the trouble.

Mike's given command is incomplete

System.FileName:~=". 1.

but, if you use

System.FileName:~=". 1."

That works very nicely. The ending parenthesis is required. It DID find the requisite files in the modified form.

Now, mind you, there is no particular effort expended by microsoft to make this method easy to find.....

Thank you


By the way, there were in excess of 10,000 of those files. Took a while to even delete them wholesale.

Mike Amick
09-28-2015, 02:15 AM
Good for you Jer ..

Thats funny too .. cause when I was testing that I had all intentions of adding that second
parentheses, but as I was typing, the correct result popped up on "my" machine before doing that
so I stopped.

Anyways .. good for you.

jhe.1973
09-28-2015, 02:34 AM
........................

Better living through computers................

Glad to hear that you have a solution! This is a thread I definitely need to save.

Just thought I'd take a quick photo of this cartoon that I have above my computer:

http://i1096.photobucket.com/albums/g327/jhe-1973/Hate%20technology_zps3ygwboco.jpg

Then I got the giggles when I realized that I was using a digital camera, I enhanced it to increase the contrast and I am using the internet to post it!

Yeah, I'm a jerk!

:D

Lew Hartswick
09-28-2015, 08:20 AM
Just a bit: Those " " are not parentheses, They are Quotes. These ( ) are parentheses. Now the big question is ,
What do various people call these, { } . ??? I was taught they are Braces, but I've heard several other names.
I guess Brackets is the accepted for [ ] those isn't it ??
...lew...

Mike Nash
09-28-2015, 08:23 AM
Well, I located the trouble.

Mike's given command is incomplete

System.FileName:~=". 1.

but, if you use

System.FileName:~=". 1."

That works very nicely. The ending parenthesis is required. It DID find the requisite files in the modified form.

Now, mind you, there is no particular effort expended by microsoft to make this method easy to find.....

Thank you


By the way, there were in excess of 10,000 of those files. Took a while to even delete them wholesale.

I'll admit I wondered about the missing double quote (not parenthesis as here -> ).

lynnl
09-28-2015, 09:03 AM
Just a bit: Those " " are not parentheses, They are Quotes. These ( ) are parentheses. Now the big question is ,
What do various people call these, { } . ??? I was taught they are Braces, but I've heard several other names.
I guess Brackets is the accepted for [ ] those isn't it ??
...lew...

I first learned "{" and "}" as braces, but now I find the term "curly bracket" less ambiguous.

J Tiers
09-28-2015, 09:26 AM
Heh... I did call it that, didn't I?

Well it was late and I had just deleted 10000 files, TWICE.

I notice that the point got through anyway.