> čet 16.05.2019., at 19.49, Dominic Giampaolo wrote: Hi Dominic, thanks for kicking in and giving some more insights on the issue.
> I didn't know that kFSEventStreamEventFlagRootChanged is ignored in a > sandboxed environment. That's unfortunate. Well, I think my choice of words was a bit unfortunate. I didn't really want to say that kFSEventStreamEventFlagRootChanged is ignored in a sandboxed environment, but rather that it "doesn't work", so the actual behaviour is like it's ignored. > The "WatchRoot" flag is implemented on the client side of the FSEvents > framework and it's just using kqueue's on each of the parent directories to > watch for changes. You may be able to just use that. And now that you explained how kFSEventStreamEventFlagRootChanged is actually implemented, I understand why it doesn't work. > Given that your app is sandboxed it probably isn't operating on files outside > of its sandbox. If that's true then you may be able to just watch the > parents up to the root of your sandbox and then stop. Sandbox containers > effectively live in hidden locations that the user never sees or can modify > so I think you're safe. > If the files you're watching all live within your sandbox, the best thing is > to work with paths that are relative to the root of your sandbox (or only > construct full paths by prefixing the sandbox root just before you go to use > the path). None of the above is my case. I'll go into more details one more time, just to explain my actual case, draw conclusion and ask for eventual workarounds. It may be useful to someone else as well. The application I'm working on is just a tiny client for the much larger informational system. For its functioning, the system relies on a bunch of configuration files, which can be scattered ALL OVER the filesystem(s). The application needs to read those configuration files and present various configuration options and parameters in a nice UI. The application also should monitor configuration files for changes and act on any file change and update its UI accordingly. From the above it's clear the application doesn't operate on files within its own sandbox. The read access to above mentioned configuration files is obtained through a standard way in a sandboxed application, using NSOpenPanel/powerbox. File changes are monitored using FSEvents API, with streams created with kFSEventStreamCreateFlagFileEvents and kFSEventStreamCreateFlagWatchRoot flags. Monitoring worked like a charm in a non-sandboxed application. Now, when I started playing around with FSEvents API in a sandboxed environment, I discovered an interesting thing. For the sake of clarity, let's say the application needs to monitor a configuration file with full path being "/Folder1/ Folder2/Folder3/File4". I expected that, in order to monitor this file for changes in a sandboxed environment, I have to obtain (at least) read access to it using some standard sandbox-friendly way (powerbox of temporary entitlements). However, it turned out the application can monitor changes to the file without obtaining any rights to it at all. After I thought about it, it actually seemed logical; fseventsd daemon registers changes to the file and will notify any process subscribed to file's path regardless of whether that process has any access rights to a file on that path or not. FSEvents API is strictly file-path based. Not that this "discovery" was of a particular interest at all, since the application has already obtained read access to the file in order to read configuration parameters. I just wanted to point it out as an interesting effect due to FSEvents API being file-path based. And so, the application is capable of monitoring all changes to the file even in the sandboxed environment, except for kFSEventStreamEventFlagRootChanged. And here is why… According to Dominic, root changes are actually implemented using a series of kqueue's on directories "/Folder1", "/Folder1/Folder2" and "/Folder1/Folder2/Folder3". Since kqueue is registered on a file descriptor opened with at least O_EVTONLY flag passed, the whole kFSEventStreamCreateFlagWatchRoot implementation fails, because even though the application has read access to "/Folder1/ Folder2/ Folder3/File4" obtained through the powerbox, it still has no rights to access any of three parent directories. Opening file descriptors on those directories fails and consequently kqueue's requiring those descriptors fail as well. With all the above being said, it's clear even more than before that in order to catch kFSEventStreamEventFlagRootChanged events in a sandboxed environment, one has to watch the whole filesystem at path "/" unfortunately. I never really liked that idea due to a flood of file events the application is not interested in at all. And that was even before Dominic mentioned other concerns, such are cpu usage, power consumption, and memory usage. For all those reasons, I'll try to convince the "owner" of the application to drop notifications on kFSEventStreamEventFlagRootChanged events. I hope they will accept it. I strongly believe having it is not worthy of all drawbacks of watching changes across the all filesystems at "/". Of course, if anyone has some other ideas how to solve the problem completely, I'm very willing to hear it. -- Dragan _______________________________________________ Do not post admin requests to the list. They will be ignored. Filesystem-dev mailing list (Filesystem-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
