1

I have a sandboxed NSDocument based app with a Spotlight plugin to index my custom documents.

During testing I noticed a lot of errors being logged to the console by the Spotlight plugin as it indexes a document:

5/4/15 3:11:18.765 PM sandboxd[432]: ([579]) mdworker(579) deny file-write-data 
  /Users/test/Desktop/test.document 
  (import fstype:hfs fsflag:480D000 flags:240000005E diag:0 isXCode:0
    uti:com.test.document 
  plugin:/TestApp.app/Contents/Library/Spotlight/TestApp Spotlight Importer.mdimporter - 
  find suspect file using: sudo mdutil -t 407144)

It appears as if the plugin attempts to write to the file it indexes (although it has only read-only access).

In my Spotlight plugin implementation I don't do anything in particular to write to the document. All I do is initialize my NSDocument subclass to read from the document: 

[[TTCustomDocument alloc] initWithContentsOfURL:url ofType:contentType error:outError];

Here's the stack trace:

Thread 4:
0   libsystem_kernel.dylib          0x00007fff9015ee92 __mac_syscall + 10
1   libsystem_sandbox.dylib         0x00007fff910140b0 sandbox_check + 206
2   AppKit                          0x00007fff8f75fc38 -[NSDocument _autosavingPossibilityConcern] + 213
3   AppKit                          0x00007fff8f75fb02 -[NSDocument _checkAutosavingPossibilityAndReturnError:] + 60
4   AppKit                          0x00007fff8f75f9cf -[NSDocument _checkAutosavingAndReturnError:] + 26
5   AppKit                          0x00007fff8f75f97e -[NSDocument _checkAutosavingAndUpdateLockedState] + 26
6   AppKit                          0x00007fff8f75e420 -[NSDocument _initWithContentsOfURL:ofType:error:] + 319
7   AppKit                          0x00007fff8f75e056 -[NSDocument initWithContentsOfURL:ofType:error:] + 230

Looks like the autosaving check is somehow attempting to write to the document.

Is there anything I can do about this? Is there some sort of read-only mode to open an NSDocument?

Update:

To reproduce:

  1. Create a new Xcode project: "Cocoa document based app"
  2. Add a Spotlight plugin
  3. Code for the NSDocument implementation and Spotlight plugin are here: https://gist.github.com/anonymous/c4929586dfa11a473673
Mark
  • 6,647
  • 1
  • 45
  • 88

1 Answers1

0

Okay, so where's the code for -[TTCustomDocument initWithContentsOfURL:ofType:error:] or any other custom initialization code, as well as your -readFromURL:ofType:error and related code? It's likely you're triggering something from one of these (init... and/or read...) methods that causes the document to be flagged as dirty (having unsaved changes), which results in the autosave system being triggered. This is improper behavior in your TTCustomDocument class.

My guess is you're triggering something that registered a change with the document's undo manager. Easy to do if it's a Core Data document and you're setting up some initial data; also easy to do if you set up initial data in a way that calls one of your own undo-aware funnel methods. The easiest work-around (recommended by the documentation) is to call [self.undoManager disableUndoRegistration]; before the changes and `[self.undoManager enableUndoRegistration]; after the changes and before returning self.

Joshua Nozzi
  • 60,946
  • 14
  • 140
  • 135
  • Thanks for looking into this. I did not override `initWithContentsOfURL:ofType:error:`. In `init` I set up some internal objects. I do use `[self.undoManager disableUndoRegistration]` when reading the contents. Looking at the stack trace, I think it's checking right away if the document can be autosaved. I overrode `+ (BOOL)autosavesInPlace` to return YES. – Mark May 07 '15 at 06:10
  • I reproduced this with a sample app based on the Xcode document app template. The problem only occurs if `autosavesInPlace` returns YES. I'm going to file a bug report to see what they say at Apple about this. – Mark May 07 '15 at 08:46
  • What internal objects? How do you set them up? These are critical details. – Joshua Nozzi May 07 '15 at 12:49
  • I added a gist with the relevant code to the question. – Mark May 08 '15 at 06:16