Date
1 - 12 of 12
NSFIleManager enumeratorAtPath problem
|
Dave
Hi,
I can’t for the life of see what is wrong with the following method. I’m basically doing the same as in the NSFileManager but I can’t seem to get it to work. The enumeratorAtPath: methods returns what appears to be a valid enumerator, but the “while” statement fails on the first call. myExistsFlag and myFolderFlag are set to YES. Can anyone spot the problem? I’ve been at it about an hour now. Thanks a lot Dave myDictionary = [self newDictionaryFromPath:@"/Users/devDave/Desktop/Accounts/"]; //***************************************************************************************************** -(NSDictionary*) newDictionaryFromPath:(NSString*) theSourceFilePathString { NSFileManager* myFileManager; NSString* myFilePathString; NSDirectoryEnumerator* myDirectoryEnumarator; NSMutableDictionary* myDictionary; BOOL myExistsFlag; BOOL myFolderFlag; myDictionary = [[NSMutableDictionary alloc] init]; myFileManager = [NSFileManager defaultManager]; myExistsFlag = [myFileManager fileExistsAtPath:theSourceFilePathString isDirectory:&myFolderFlag]; myDirectoryEnumarator = [myFileManager enumeratorAtPath:theSourceFilePathString]; while (myFilePathString = [myDirectoryEnumarator nextObject]) { if ([myDictionary objectForKey:myFilePathString] != nil) { NSLog(@"Dupe File: %@",myFilePathString); continue; } NSLog(@"Added File: %@",myFilePathString); [myDictionary setObject:myFilePathString forKey:myFilePathString]; } return myDictionary; } |
|
|
|
Sak Wathanasin
Can anyone spot the problemIn the code you posted, there was no check for the value of myFolderFlag on return from fileExistsAtPath:, so are you sure it's a directory? Doc for enumeratorAtPath: says: "Return Value An NSDirectoryEnumerator object that enumerates the contents of the directory at path. If path is a filename, the method returns an enumerator object that enumerates no files—the first call to nextObject will return nil." Regards Sak Wathanasin Network Analysis Ltd |
|
|
|
Dave
As I said,
toggle quoted message
Show quoted text
myExistsFlag and myFolderFlag are set to YES. So the folder exists, I copied and pasted the Path from the finder. Also I've tried it on a number of different folders and it still doesn’t work. There are definitely files present in the folders I’ve tried. Cheers Dave On 6 Jun 2019, at 12:27, Sak Wathanasin <sw@...> wrote:Can anyone spot the problemIn the code you posted, there was no check for the value of myFolderFlag |
|
|
|
Sandor Szatmari
Are the folders actual folders? Or symlinks?
toggle quoted message
Show quoted text
What OS, SDK, etc? Sandor On Jun 6, 2019, at 07:06, Dave <dave@...> wrote: |
|
|
|
Dave
Hi,
toggle quoted message
Show quoted text
MacOS 10.13.6 Deployment Target 10.13 Yes, they are real folders, here is one that doesn’t work: /Users/develop/Desktop/Accounts/ This has a number of .xls files and a couple of .pdf files. Cheers Dave
|
|
|
|
Steve Mills
On Jun 6, 2019, at 08:17:32, Dave <dave@...> wrote:
Just for kicks, what if you remove the trailing '/'? -- Steve Mills Drummer, Mac geek |
|
|
|
Dave
I’ve already tried it, same result.
toggle quoted message
Show quoted text
Can’t think of anything else that could be going wrong! On 6 Jun 2019, at 15:26, Steve Mills via Groups.Io <sjmills@...> wrote: |
|
|
|
Steve Mills
On Jun 6, 2019, at 08:45:32, Dave <dave@...> wrote:
Wait, is security getting in the way? Is the app sandboxed? If so, you can't just throw a folder at it and expect it to work. What if you choose the folder via NSOpenPanel or add Desktop as one of the needed folders in the sandbox portion of the target settings (I don't have Xcode open at the moment and need to get to the office)? -- Steve Mills Drummer, Mac geek |
|
|
|
Dave
Hi,
toggle quoted message
Show quoted text
Yes! It was sandboxing I turned it off and all works ok now! Thanks Dave On 6 Jun 2019, at 15:49, Steve Mills via Groups.Io <sjmills@...> wrote: |
|
|
|
Leo
I read this discussion with interest... that's good to know!
May I also suggest to submit it as a bug to Apple. That is, if a function fails because of sandboxing then it shouldn't just fail silently. There should be a clear error or exception: The operation cannot be performed because sandboxing is enabled. Otherwise, Apple once again stabs developers in the back with its pseudo-security mumbo-jumbo. |
|
|
The OP was calling -[NSFileManager enumeratorAtPath:], which is an old API that predates NSError, so failing silently is all it can do. (Cocoa APIs do not throw exceptions except in the case of programmer errors like assertion failures.) For this reason there is a newer method, -[enumeratorAtURL:…], which does return errors. If the OP had been using that API they'd have gotten an error. IMO the old method should have been deprecated years ago.
In what way is it "pseudo" security or "mumbo-jumbo" to restrict access to the user's files? If I download some little app from an unknown developer to batch-resize JPEGs, then I really don't want it to have access to all of my emails, or my tax returns, or even to photos that I didn't explicitly tell it to resize. If you think those are far-fetched examples, take a look at the kind of privacy nightmares that happen with Android apps. There are many instances of innocent-seeming apps on the Google Play store that slurped up people's private information and uploaded it to the developers' servers. Or worse, consider the spread of ransomware on Windows. —Jens |
|
|
|
Leo
Jens, Thanks for the info on the enumeratorAtURL: method. I take back my suggestion regarding the bug then. Regarding my pseudo-security remarks: yes, I agree of course that some of the measures make sense and are essential. However, I do think that some of them unnecessary. If we take the same example with batch processing you mentioned: sandboxing applies one debilitating restriction on batch processing where your target output folder cannot be specified as the parent folder of each file (or a subfolder in the parent folder etc.) That's because the output folder for all files in the batch must be a specific folder explicitly selected by the user. There are worse things like Apple Event sandboxing introduced on Mojave. Users are now being pestered by cryptic messages that no one reads or understands anyway - and OKs automatically regardless. And if the user hits Don't Allow by mistake, then there's no even obvious way to restore the permissions... But I'm sure you're aware of all this anyway. I might be wrong, but to me it's pseudo-security. Many of those security features are also poorly implemented and documented - which, in my view, puts a serious burden on developers. I know that I wasted countless hours on the aforementioned Apple Event sandboxing. Admittedly, right now I'm especially annoyed as I'm in the process of implementing notarization for my apps. Which is also poorly documented with weird issues arising on every step of the process. Tons of time is already wasted on this instead of doing something productive. That's what mostly made me chime in on the subject. Cheer, Leo |
|
|