NSFilePresenter -presentedSubitemDidAppearAtURL: method never gets called

Asked 12/9, 2012 at 13:49 Answered 14/10, 2015 at 22:30

Solved objective-c cocoa nsfilecoordinator

I have an object which conforms to NSFilePresenter protocol that represents my document-based application document package. When a new file is created inside the package, either programmatically using NSFileManager with proper NSFileCoordination methods or via Finder i only got -presentedSubitemDidChangeAtURL: event, but not seeming so obvious in this case -presentedSubitemDidAppearAtURL:.

Is this an expected behavior or i am doing something wrong?

The comments on -presentedSubitemDidAppearAtURL: in NSFilePresenter state it clear:

Be notified that a file or directory contained by the directory has been added. If this method is not implemented but -presentedItemDidChange is, and the directory is actually a file package, then the file coordination machinery will invoke -presentedItemDidChange instead.

Supermarket answered 12/9, 2012 at 13:49 Comment(4)

I suppose you did not implement -presentedItemDidChange? – Libbielibbna 4/4, 2013 at 12:53

Here's a nice posting related to this issue, and my conclusion is; Don't use NSFilePresenter. – Araucania 12/11, 2014 at 0:8

GCD seems to be the way to go. Handling Filesystem Events with GCD – Araucania 12/11, 2014 at 1:58

@Eonil like you have any options to choose from. – Anatomist 23/12, 2015 at 18:13

After struggling with this exact issue for quite a while, I opened a technical support issue with Apple. Their response was that this is a bug, and the only thing we can do right now is to do everything through -presentedSubitemDidChangeAtURL:.

I would encourage anyone encountering this issue to file a bug (https://bugreport.apple.com) to encourage Apple to get this problem fixed as soon as possible.

Ecclesiastes answered 13/10, 2013 at 9:42 Comment(8)

Did Apple's response to you indicate the extent of the "bug"? Is it simply that -presentedSubitemDidAppearAtURL:, -accommodatePresentedSubitemDeletionAtURL:completionHandler: et. al. are not yet handled by the NSFileCoordinator API, or are there cases where they would be called? – Ramillies 20/11, 2013 at 9:42

They didn't disclose any details to me, so I'm not sure, unfortunately. – Ecclesiastes 20/11, 2013 at 14:54

Still same in 2014 Nov. I wasted about a day for this. Thanks anyway. – Araucania 12/11, 2014 at 0:0

Now at iOS 9.1 – still the same. – Hellman 12/11, 2015 at 13:24

For god's sake, iOS 9.2 same bug. – Anatomist 23/12, 2015 at 18:7

2016, iOS 10b7 and still going strong :) – Scholiast 25/8, 2016 at 17:27

It's 2021 now, and the bug is still not fixed in iOS 14.6 – Pejoration 5/7, 2021 at 16:46

It's 2022 and this bug is still in macOS Monterey 12.0.1 -- which should be similar to iOS 15.x as they both rely on the Foundation frameworks NSFilePresenter and NSFileCoordinator. I considered that perhaps this had to do with the document based app having some automatic behavior in NSDocument -- or one of the hidden classes in the class-cluster. However adding another file presenter outside of the document subclass has the same behavior: only some of the delegate methods are called. and the most important method that provides a block before an item is deleted seems never to be called. – Ohaus 28/2, 2022 at 11:8

-2

https://developer.apple.com/library/mac/documentation/Foundation/Reference/NSFilePresenter_protocol/

Your presenter objects are not notified about changes made directly using low-level read and write calls to the file. Only changes that go through a file coordinator result in notifications.

Shoop answered 14/10, 2015 at 22:30 Comment(1)

the original post mentions that he did use file coordinator. specifically, with proper NSFileCoordination methods or via Finder. And note that the Finder does use file coordination, so all the delegate calls should be made. – Ohaus 28/2, 2022 at 11:1

Recommended topics

Hot tags