Find (search) Very Slow
 

Our mac network of various systems is using Window2000 server, there are currently two systems right now that are using OS X, with more to be added soon, but one problem we have has from the begining is the tremendeously slow find function. Through OS 9 the Find program works flawlessly but through OS X search for the same file or any other takes forever, we faster finding the file manually.

Can this be improved to respond like in OS 9 or better? patch etc. :(
I do hope this problem is something that can be fixed and is fixed in the Panther update.

thanks

more details please
 

Please tell us in more detail what you are doing. I.e.
1) What are you typing into the Find dialog?
2) Are you typing the whole filename? (Give us a specific example.)
3) What location(s) are you specifying to be searched? (in the top of the Find dialog)
4) Where is the file that you are looking for? (I.e. is it on a local drive, a network drive, a CDROM?)

You had previously (in another thread) reported network slowness. Perhaps this is the basis of the problem. (It is possible to have network problems that show up only in OS X and not OS 9.) Perhaps your Mac's Ethernet settings are incompatible with those used by other parts of your network?
See discussion on this thread:
http://forums.macosxhints.com/showth...=&postid=56740
and perhaps search for similar discussions.

It would also be useful to check if this slowness is also experienced when you use the 'find' command in Terminal to do similar searches.
E.g. if you are searching for a file that starts with "report" and you know it is on the network drive named "fred", you could do the search with the folowing command in Terminal:
find /Volumes/fred -name 'report*'

locate db
 

I suggest using the locate database rather than the Finder's Find feature. I update the locate database nightly and use either the terminal or Locator 0.7.3 (http://www.sebastian-krauss.de/software/) to search for file names.

This script updates the locate database in exactly the same manner as the weekly periodic script, rather than using the more insecure sudo /usr/libexec/locate.updatedb. Run nightly or as often as necessary.
Locator 0.7.3 (linked above) is a nice GUI for searching the locate database. If you want similar terminal functionality, here is a tcsh alias:
alias locator "locate \* | grep -i \!* | less"

Re: locate db
 

While I agree that using 'locate' (and its GUI version) is often better than using find (or File/Find),
the main point of this thread is to figure out why the Finder's Find is slow for the original poster. Not merely slower than using 'locate' - slower than using OS 9 File/Find. As I said earlier, I suspect this is symptomatic of a network problem.

I can't tell
 

I am searching for files as I would in OS 9 either by complete name or either partial (command F)-- no matter which, OS 9 responds quickly while OS X is continuously searching.

I love the input of all but I really need to find a solution through a GUI interface rather than terminal- the others will KILL me if terminal was the only way.

Locator I wil try, but is there something that I may be able to have Windows IT look at, cause beyond my usual use of mac systems I really don't know much about the IT terms and lingo.


Thanks

forgot to mention
 

It is a window 200 server that we are searching on.
transferring files no problem but searching - god help.

Batty@,
I've been looking for answers for the exact same problem with our network. It seems that our basic set-up is identical to yours. I have been checking and posting on other forums as well and I will update you if I find out anything useful.

network ?
 

The reason for doing the 'find' command in Terminal as I suggested above is merely to get more information about the problem. At the moment we can't look for a solution since we don't know what the real problem is.
as I have said earlier, I suspect that the real problem is a network problem. You still haven't responded to my request for details on exactly what you are searching for and how you do the search (see my specific questions above - now edited to number them for clarity).

But if it is true that slowness is associated with accessing the network (i.e. searches on the local drive are fast), then it would seem to be a network problem. And if so, we need to get more info about your network configuration. You should read the thread that I linked to above about Ethernet configuration and ask your IT guys to test basic network throughput both to and from the Windows server machine and your Mac.

Even some basic network tests would be useful.
E.g. what do you get when you 'ping' the server?
What do you get when you are logged onto the Windows server and do a ping of the Mac?
How does it compare to the same thing in OS 9 ?
Note: you can do 'ping' in Terminal or you can use "Network Utility" to do it in OS X. In OS 9 you will need to download a 3rd-party utility - e.g. WhatRoute.

And what do you get when you do the following command in Terminal ?
ifconfig

Ok here goes...
 

Sorry but I thought I answered the questions in the respond post.

1) we type parts of a file name; ie-
"SV2569665 Detroit trout" depending if we need the number, or the city, or the fish we would type in the corresponding request- I'm looking for something Detroit related, I will type "Detroit". (no quotes of course)

2) see answer one.

3 - 4) same answer for both the search and file is on the network drive.

PING - 10 pings only (Feel like I'm in a submarine) here is what it gave: (pinging to the server).

Ping has started ...

PING artcom (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: icmp_seq=0 ttl=128 time=0.325 ms
64 bytes from 10.0.0.2: icmp_seq=1 ttl=128 time=0.286 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=128 time=0.305 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=128 time=0.273 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=128 time=0.295 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=128 time=0.292 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=128 time=0.296 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=128 time=0.294 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=128 time=0.29 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=128 time=0.285 ms

--- artcom ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 0.273/0.294/0.325 ms
--don't know what all this means- mind all this is through after hours (if this makes a difference)

Terminal:ifconfig

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::20a:95ff:fe78:80b0%en0 prefixlen 64 scopeid 0x4
inet 10.0.40.17 netmask 0xff000000 broadcast 10.255.255.255
ether 00:0a:95:78:80:b0
media: autoselect (100baseTX <half-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <half-duplex,hw-loopback> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback> 100baseTX <half-duplex> 100baseTX <half-duplex,hw-loopback> 100baseTX <full-duplex> 100baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex> 1000baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex,flow-control> 1000baseTX <full-duplex,flow-control,hw-loopback>


hope this info helps you-- I have no clue what I'm looking at.

narrow down the problem
 

Your 'ping's look good - no indication of trouble there. But I'm guessing (you neglected to say) that you were doing the ping from your OS X machine to the Windows server. What about the other direction? Try doing a ping to your OS X machine from the Windows machine.

And, unless I missed it, you still haven't confirmed whether or not the problem is only with searches over the network. Is File/Find fast when you do searches of the local drive?

You should present your 'ifconfig' results to whoever is in charge of your network. In particular check that the "100baseTX <half-duplex>" setting which seems to be being used is the correct one for your network.
Ask your network guy to do some tests of the network connection in both directions between your OS X machine and the Windows server. Need to look for collisions, etc. One way of doing this on OS X is with 'netstat -i'

You would want to do all of these tests (including redoing the 'ping's when you experience the slowness. It may well be something that only happens when the network is busy.

You said that file transfers are speedy enough. What transfer speed are you getting? A utility like Net Monitor (linked to in the thread I referred to above) would make it easy to measure this.

Ok
 

Yes did mention the ping is from the OSX to the server.

The slowdown is only when searching from the network server not the local disk (my hard drive).

I will have to ask if any of the ITs would mind trouble shooting, they are mainly for Windows systems not Macs, we don't have our own- most of the trouble shooting we have to do ourselves.


Thanks

ping
 

By the way, that feeling isn't a coincidence: see The Story of Ping

diagnostic tool
 

Even though your network problem is with your LAN, the following diagnostic tool that tests your Internet connection might give some clues as to the problem:
http://miranda.ctd.anl.gov:7123/

Run this on the Mac that is having the slow search problem. Look at the Statistics after the test has finished. It tells you if it detected any problems (e.g. duplex mismatch) with your network connection.

Hayne,
Ran the diagnostic javascript you mentioned. No problems. Running 100 Full Duplex. File transfer speeds are good both ways. Ping is good both ways. "Find" will find directories (folders) within a few seconds but will spin indefinitely when looking for specific files by name. I'm talking about basic searches such as "find file 8S4636.eps on server Y". Find works well with our OS9 machines. Only our OSX 10.2.6 stations can't search. My setup is the same as Batty's as far as I can tell. Perhaps some sort of Indexing issue; HFS+? I can't index these server volumes, either through the "get info" or through the terminal. The former method dies with a server disconnect and the latter gives an I/O error.

Hmm - the fact that it can find folders but not files should be a big clue.Could you please try doing a search using the 'find' command in Terminal? For the example you mentioned, it would be:
find /Volumes/Y -name 8S4636.eps
For comparison, also do a search using 'find' for a folder.
I'm not too surprised that you can't index the server volumes since it is a foreign (non-HFS+) filesystem.

Running the find command in terminal brings up another prompt when I hit enter.

[Computer:~] davew% find /Volumes/Y -name 9M4315_BL
[Computer:~] davew%

My UNIX is rusty so please bare with me. What should I be looking for?

That would mean that it didn't find anything.
Is the name of the volume really "Y" ?
Is the full filename really "9M4315_BL" ? No suffix or anything?

The file name is actually correct with no suffix, but I changed the name of the server in the email - just for security. This is an actual file that exists on this server and I can access it readily through the finder. I also tried various other file names as well. FYI - the prompt comes back instantly as soon as I hit return.

Hmm - this is strange.
What directory/folder is the file in?
Please show us the results of doing an 'ls -l' command (in Terminal) on that folder. That command is phonetically: "ell sss minus ell" by the way. E.g. if the file is in the folder /Volumes/Y/mystuff/folderA then the command would be:
ls -l /Volumes/Y/mystuff/folderA

if there are a lot of files in that folder, then edit the result to just show us the first few lines and then the line for the file in question.

And it's fine to keep using "Y" for the name of your volume - even though there are really no security implications since the volume name is not something that is accessible over Internet - at least not without an IP address, etc.
But please confirm that the volume name doesn't have any spaces or other special characters in it.

[Computer:~] davew% ls -l /Volumes/Y/SB53/SB53_LORES/
ls: /Volumes/Y/SB53/SB53_LORES/: No such file or directory

The directory structure above is correct. I had the IT guy check it.

If I try:

[Computer:~] davew% ls -l /Volumes/Y/
[Computer:~] davew%

What am I missing?

PS. I haven't posted the server name because it's the name of my company and I don't want it biting me in the butt later. It's one word and I've checked the spelling thoroughly. There are no typos in any of the commands.