finding the the files using cocoa

Discussion in 'Mac Programming' started by hrishidev, Apr 6, 2008.

  1. macrumors regular

    Dec 3, 2007
    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];
    			//directory related code here
    		NSArray *ContentOfDirectory=[flManager contentsOfDirectoryAtPath:m_szPath error:NULL];
    		int contentcount=[ContentOfDirectory count];
    		int i;
    				NSString *fileName=[ContentOfDirectory objectAtIndex:i];
    				NSString *path=[m_szPath stringByAppendingFormat:@"%@%@",@"/",fileName];
    				if([flManager isDeletableFileAtPath:path])
    					[self scanPath:path];
    			//file related code here
    			NSString *msg=[NSString stringWithFormat:@"%@%@",@" -File ",[m_szPath lastPathComponent]];

    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
  2. macrumors regular

    Feb 18, 2007

    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.
  3. macrumors 68020


    Sep 8, 2003
    +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?
  4. thread starter macrumors regular

    Dec 3, 2007
    "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 .....
  5. macrumors G5


    Nov 25, 2005
    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.
  6. macrumors 68020


    Sep 8, 2003
    +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.
  7. thread starter macrumors regular

    Dec 3, 2007
    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
  8. Moderator emeritus


    Jun 15, 2000
    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.
  9. macrumors 68020


    Sep 8, 2003
    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?
  10. macrumors 65816


    Jun 3, 2007
    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?

Share This Page