> On Oct 22, 2016, at 2:42 PM, Jean Suisse <jean.li...@gmail.com> wrote:
>
>>
>> On 22 Oct 2016, at 21:24, Quincey Morris
>> <quinceymor...@rivergatesoftware.com
>> <mailto:quinceymor...@rivergatesoftware.com>> wrote:
>>
>> On Oct 22, 2016, at 11:42 , Jean Suisse <jean.li...@gmail.com
>> <mailto:jean.li...@gmail.com> <mailto:jean.li...@gmail.com
>> <mailto:jean.li...@gmail.com>>> wrote:
>>>
>>> My app should get an access denied error (the enumerator should be nil for
>>> instance). It shouldn’t crash.
>>
>> It can’t return nil, because that is used to signal the end of the
>> enumeration. I agree it’s nasty if it crashes, though.
>
> I am not talking about enumerator?.nextObject() but about
> manager.enumerator(at: includingPropertiesForKeys: options:), which in the
> API return an optional FileManager.DirectoryEnumerator?, which I expect to be
> nil when there is nothing to enumerate.
>
> However, the doc states:
>
> Returns: An NSDirectoryEnumerator object that enumerates the contents
> of the directory at url. If url is a filename, the method returns an
> enumerator object that enumerates no files—the first call to
> nextObject()returns nil.
>
> So, why make it an optional value at all?
>
>>
>>> Though it looks like I am trying to access "/.DocumentRevisions-V100/“, it
>>> is not what I am trying to achieve.
>>>
>>> At some point my app needs to enumerate user-selected directories. The
>>> issue is I get a crash when directories such as "/.DocumentRevisions-V100/“
>>> are present.
>>> I cannon reasonably maintain a list of “don’t enumerate” directories.
>>
>> It’s still not quite clear what your real code is trying to do. If you were
>> enumerating the *root* directory *shallowly*
>> (.skipsSubdirectoryDescendants), and you hit this directory, you should
>> *not* try to descend explicitly into this directory (or any directory whose
>> name begins with a period, I suppose) as your sample code does. If you were
>> doing a deep enumeration from the root directory, you wouldn’t be executing
>> shallow enumeration code as in your sample code.
>
> Yes, I enumerate shallowly. Yes I hit the directory. And yes, the user may
> take an action that will lead my app to try enumerating directories such as
> "/.DocumentRevisions-V100/“ shallowly.
> The finder doesn’t crash when I try to open .DocumentRevisions-V100. Neither
> should my app.
>
>> Can you use the .skipsHiddenFiles option for your real enumerator? That will
>> skip files and directories whose name starts with a period.
>
> I could. But I still may hit directories that the user does not have the
> permission to access. .DocumentRevisions-V100 is really just for the example.
>
>>
>>> To refine, what difference is there between ObjC’s
>>> for (NSURL* file in enumerator)
>>>
>>> and swift’s
>>>
>>> while let file = enumerator?.nextObject() as? URL
>>> ?
>>
>> You’re comparing unlike things. Regardless of language, “for … in” and
>> “while … nextObject” use different mechanisms for maintaining state between
>> iterations. What does the Swift version of the “for … in” loop do?
>
> Jens asked if an equivalent in ObjC would crash. That’s what I came up with.
> The for … in loop performs gathers data about the file and folders, puts them
> in an array, returns it to the caller function, then the app continues
> interacting with the user.
I just tried it myself, and indeed got your crash. The backtrace is:
* thread #1: tid = 0x3f24f, 0x00000001000ca265 foo`static
Foundation.DateComponents._unconditionallyBridgeFromObjectiveC
(Swift.Optional<__ObjC.NSDateComponents>) -> Foundation.DateComponents with
unmangled suffix "_merged" + 85, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x00000001000ca265 foo`static
Foundation.DateComponents._unconditionallyBridgeFromObjectiveC
(Swift.Optional<__ObjC.NSDateComponents>) -> Foundation.DateComponents with
unmangled suffix "_merged" + 85
frame #1: 0x000000010000204b foo`thunk + 59 at main.swift:0
frame #2: 0x00007fff78be6c82 Foundation`-[NSURLDirectoryEnumerator
nextObject] + 101
* frame #3: 0x0000000100001888 foo`main + 952 at main.swift:17
frame #4: 0x00007fff8c1d5255 libdyld.dylib`start + 1
It looks like we’ve got a bridging issue here; my guess is that Objective-C is
presenting nil to something that Swift didn’t expect to be optional. It’s
pretty obviously a bug; I’d file a Radar on it.
Charles
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
