POSIX IP Address/file Question


Below is a search statement which has worked flawlessly until this morning when our server kicked off all users without notice. When it came back online, the following search kept returning {“”}, no matter what was entered. I figured the filepath was no longer valid b/c a manual inspection of the file location found the file (die_num) being search for.

When I resolved the filepath, this is what finder returned (the -2 in the ip address):

display dialog “Search OS Artwork…” with title “VPG-2011 OS Artwork Search System” default answer “Enter File Number Here…”
set Die_num to text returned of result

set files_found to paragraphs of (do shell script "mdfind  -onlyin /Volumes/ " & Die_num)
set total_files to count files_found

My question is about the -2 after the IP address in the filepath. I’ve never seen this before and is the reason the script failed. Before, it resolved to

Why is this -2 there now and why does the script work with it now?

I’m just wondering if the server is having file/sector/disk problems and if it’s about to fail. It’s not going to be efficient if I have to check this filepath every time we log into the server…

Thanks for all you help! As always, I appreciate ANY and ALL input.


The main reason is that mdfind is never going to look for the file when it searches but it searches in a database that contains email messages, file paths etc… (all the stuff that can be found with spotlight). This means that the -only-in option doesn’t mean that it searches inside that directory but it only means that the path of the item needs to start with ‘your path’. This -2 is just a postfix to avoid double names. Like for instance I have a server at the office and at home with ip and both have spotlight enabled. Then the second second server connected to my machine is stored as in the database. Also a server crash can happen sometimes that that spotlight identify the same server as a new server and will ad a number to it’s name.

The solution is emptying the spotlight database and rebuild it. I’ve never done this with network volume but for the root volume I’ve used this and maybe this works too with network volumes.

try sudo mdutil -s /Volumes/ command first to see the status of it and maybe you can erase this manually including /Volumes/

Another reason could be that there is a damaged node in the Volumes folder. With rm you can remove this node if it’s still there.

AWESOME. Thank you so much! I will try this tomorrow when I get to work.

Is there a shell script that I could use that would find the user entered filename that wouldn’t cause this problem? I stumbled on the mdfind command, trying to find a faster alternative to finder and, it has worked great for this application (until this popped up).

If you have any recommendations to search a folder of files on a server volume, I would love to learn about it.

I’m learning real fast the way to speed is through the “shells”, so, if you have any advice or resources you can pass along, please do so…

Thanks again!

find command is much more reliable because it reads out directories.

Spotlight vs. find:
Spotlight is faster
Spotlight can search in (some) file contents
Spotlight can search on more meta data
Find is much more reliable and connected with files
Find can resolve nodes with file names because it is directory based
Find has regular expressions built-in which in some cases can refine your search (wild cards isn’t always enough)
Find is ideal for batch processing (thanks to -exec {})
Find can compare with existing files
Find is much more accurate
Find search area isn’t limited

So depending on your needs you can choose the right tool to find. If the folder is small with only a couple of hundred sub files and folders I would recommend find over mdfind. Specially with network volumes mdfind (spotlight) isn’t reliable and accurate because it is possible that you can’t find a file who is recently added to your server and still missing in the spotlight database. This isn’t possible with find, if it doesn’t find the file it isn’t there.

Thanks for the info! I’ll explore this at work today. You ROCK!

Thanks again…