macOS finding the the files using cocoa

[hrishidev]

I have to find 1 file (say "mysetting.xml" ) in every volume of Machine using cocoa ..... i wrote 1 recursive function scanPath to scan the harddisk but its taking long file (may b its going in indefinate loop )

-(void)scanPath:(NSString *)m_szPath
{
	
	NSFileManager *flManager = [NSFileManager defaultManager];
	BOOL isDir;
	[flManager fileExistsAtPath:m_szPath isDirectory:&isDir];
	
	if(isDir)
		{
			//directory related code here

		NSArray *ContentOfDirectory=[flManager contentsOfDirectoryAtPath:m_szPath error:NULL];
		int contentcount=[ContentOfDirectory count];
		int i;
		for(i=0;i<contentcount;i++)
		{
				NSString *fileName=[ContentOfDirectory objectAtIndex:i];
				NSString *path=[m_szPath stringByAppendingFormat:@"%@%@",@"/",fileName];
				
		
				if([flManager isDeletableFileAtPath:path])
				{	
					NSLog(path);
					[self scanPath:path];
				}
				
			}
			
		}
	else
		{
			//file related code here
			NSString *msg=[NSString stringWithFormat:@"%@%@",@" -File ",[m_szPath lastPathComponent]];
			NSLog(msg);
		}
}

I m calling this function
like this

[self scanPath:@"/"];

so , how to find the files in cocoa in faster way

Also, when we type anything to find in finder , it returns within seconds .....
so is there any index of all the files which i can use to acess the file

 

[Spike099]

Spotlight

I have never tried integrating with spotlight, but it sounds like spotlight will be a better match for what you want to do.

A quick google search came up with this tutorial.

 

[Krevnik]

I have never tried integrating with spotlight, but it sounds like spotlight will be a better match for what you want to do.

A quick google search came up with this tutorial.

+1, with some caveats.

Scanning the system directly in the manner shown in the OP is going to be slower than molasses, as you are actually walking the entire hierarchy looking for a file. File systems these days just can't handle that quickly when you are talking about iterating hundreds of thousands of nodes, reading blocks from disk the whole time.

Now, the caveats: Spotlight may not even really solve the problem with this code. It will make it faster, but if there is an underlying flaw in the design, it will let that flaw fester.

A question I have is: what are you attempting to achieve by scanning all drives for particular a file on it? Why can't this file be expected in a known location on the drive, and why must it be on every drive?

 

[hrishidev]

"mysetting.xml" is saved in each folder where user has created own set of settings to handle files in that folder by my Application ...

in short the file can be found at all the locations where we can use "New folder" in finder to create folder.

BTW ,started study of spotlight query programming .....

 

[gnasher729]

"mysetting.xml" is saved in each folder where user has created own set of settings to handle files in that folder by my Application ...

This sounds very worrying. You haven't said anything about what you try to achieve here, but I wouldn't want to use an application that puts xml files in lots of directories unless you give me a very, very good reason.

 

[Krevnik]

This sounds very worrying. You haven't said anything about what you try to achieve here, but I wouldn't want to use an application that puts xml files in lots of directories unless you give me a very, very good reason.

+1. There is a huge uproar over the .DS_Store files for a reason. Please don't introduce an app that compounds the issue by making it worse.

Unless you are spewing information like this across thousands of directories, you are better off simply storing the information for various paths in a single file. Hell, even if you get to the thousands of directories part, you can probably keep it fast using SQLite and CoreData.

 

[hrishidev]

My app doesnt create files everywhere like .DS_Store , but at very few places where user decides to keep the files of my app ...

BTW , spotlight query programming met my requirements .....
Thank you all

 

[kainjow]

If those locations are on a volume that has Spotlight disabled, then I don't think the code will work, but I could be wrong.

 

[Krevnik]

If those locations are on a volume that has Spotlight disabled, then I don't think the code will work, but I could be wrong.

You are right, it won't.

This is another reason to try to centralize settings or information about these locations and store it somewhere you can get to easily... rather than hunting for them.

Can you give us a vague idea why there are these folders managed by your application? Are we talking things like multiple iTunes libraries where you have these repositories with a DB describing it?

 

[Sbrocket]

but at very few places where user decides to keep the files of my app

I think the hunting for files on startup or whatever represents a lack of design forethought. Why not just keep a data store rather than writing .xml files all over the user's harddrive? Not to mention, what happens if they delete one by accident or by not knowing what it is? Are these "files of your app" actually created by the app itself, and if so why not just keep a persistent store of where these files are with linked data that you would have stuck in the .xml file instead?