FSKit Sandbox restrictions and automatic tests

I think FSKit modules have to be sandboxed, but since you're not planning to be on the App Store and thus don't need to care about App Review, have you looked at the temporary exception entitlements (https://developer.apple.com/library/archive/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/AppSandboxTemporaryExceptionEntitlements.html)? You might find the file access ones useful.

By the way, it's usually best to make a reply instead of leaving a comment. Comments are easy to miss and usually don't create notifications.

Do you know whether I can use com.apple.security.temporary-exception.files.absolute-path.read-write with /?

I think it should work, although I haven't tried it myself.

how do I log from the extension? If I use the standard logging framework, no logs arrive in the console app.

Not sure exactly which "standard logging framework" you're referring to (there's a lot of them), but I've been able to use Swift's Logger API (from os.log, I think if you're in Obj-C you'd use os_log) from my extension and it acts like logging from a regular app. If you're trying that and it's not working, then are you logging on the debug or info levels? Those don't show up in Console's streaming view by default unless you enable them in the Action menu. The more severe levels do show up by default.

Thanks for the response. I only used a comment because the forum displayed an error when I tried to reply. But writing a comment worked. Probably just bad timing.

Anyway:

I tried com.apple.security.temporary-exception.files.absolute-path.read-write with / and it worked. Nice. A few days ago I saw this older post: https://developer.apple.com/forums/thread/779672 which has a similar question. My issues might even be better solved with FSActivateOptionSyntax, but I don't know where to find the docs for it. Or how to propably use it.

I was also able to use logs again. Don't know what was wrong.

The only question remaining is: The test question. I started to write basic test, but it is really hard. I even had to use an ugly hack https://github.com/TheNoim/fskit-unionfs/blob/e8beb6598dec62365d096f834e6eec425386edef/FSKit-UnionfsTests/TestHelper.swift#L31 because sometimes after rebuilding the extension the fskitd daemon failed to start the extension for some unknown reason.

My issues might even be better solved with FSActivateOptionSyntax, but I don't know where to find the docs for it. Or how to propably use it.

Yeah, that's probably meant to be used for your situation. I think you're supposed to be able to provide a path then you can get a security-scoped URL that you can use to access that specific path while sandboxed. I briefly looked at that a while ago but I don't think most of the Info.plist keys are documented right now. Most of the "documentation" right now is just scouring the forums or Apple's open-source FSKit extensions for examples (or, if you're lucky, replies to your feedbacks), which isn't too great.

My (untested, could be wrong) assumption was that if you were to set something like

<key>shortOptions</key>
<string>abc:d:</string>

Then on the command line you'd be able to pass options like -a or -b, while -c=arg and -d=arg both take additional arguments. I never needed it for my own extension though so I didn't look too hard, but the forums post you listed suggests that the ability to get a URL from them didn't work for that OP, so I don't know if it would actually work for you. That sounds like a bug but it looks like the OP of that thread disappeared so it's not too clear what happened there.

If it doesn't work or you can't figure it out then you should probably file a bug and post it here; an Apple employee is more likely to be able to help you that way. In my experience the FSKit team has been pretty responsive to feedback when I also post about it on the forums, and even without posting.

Or, just keep using the sandbox exception and call it a day.

The only question remaining is: The test question.

Tests... I should write some for my own module...

Anyway, I think the better option is to try to separate out the logic for your file system into their own unit testable functions, then test those separately instead of trying to test it by mounting a whole volume with FSKit. Then you'd sidestep the issue around FSKit being weird when being automated. Your goal isn't really to test FSKit, it's to make sure your own file system logic is good, so I think for this kind of codebase that should be mostly sufficient.

Unfortunately to do something like the analog of a "UI test" for a regular app (but I guess without the UI... an integration test?) I don't know how to automate it very well, but ideally your unit tests cover most of the things you do need to test.