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 problem
In 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,

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@network-analysis.ltd.uk> wrote:

Can anyone spot the problem
In 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





Sandor Szatmari
 

Are the folders actual folders? Or symlinks?

What OS, SDK, etc?

Sandor

On Jun 6, 2019, at 07:06, Dave <dave@looktowindward.com> wrote:

As I said,

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@network-analysis.ltd.uk> wrote:

Can anyone spot the problem
In 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





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#972): https://apple-dev.groups.io/g/cocoa/message/972
Mute This Topic: https://groups.io/mt/31949180/342607
Group Owner: cocoa+owner@apple-dev.groups.io
Unsubscribe: https://apple-dev.groups.io/g/cocoa/leave/defanged [admin.szatmari.net@gmail.com]
-


Dave
 

Hi,

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



On 6 Jun 2019, at 13:06, Dave <dave@...> wrote:

As I said,

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 problem

In 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









Steve Mills
 

On Jun 6, 2019, at 08:17:32, Dave <dave@looktowindward.com> wrote:

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.
Just for kicks, what if you remove the trailing '/'?

--
Steve Mills
Drummer, Mac geek


Dave
 

I’ve already tried it, same result.

Can’t think of anything else that could be going wrong!

On 6 Jun 2019, at 15:26, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote:

On Jun 6, 2019, at 08:17:32, Dave <dave@looktowindward.com> wrote:

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.
Just for kicks, what if you remove the trailing '/'?

--
Steve Mills
Drummer, Mac geek




Steve Mills
 

On Jun 6, 2019, at 08:45:32, Dave <dave@looktowindward.com> wrote:

I’ve already tried it, same result.

Can’t think of anything else that could be going wrong!
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,

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=mac.com@groups.io> wrote:

On Jun 6, 2019, at 08:45:32, Dave <dave@looktowindward.com> wrote:

I’ve already tried it, same result.

Can’t think of anything else that could be going wrong!
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




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.


 



On Jun 15, 2019, at 5:27 PM, leo.r@... wrote:

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.

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.

Otherwise, Apple once again stabs developers in the back with its pseudo-security mumbo-jumbo.

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