Re: FSEvents API and sandboxing
Re: FSEvents API and sandboxing
- Subject: Re: FSEvents API and sandboxing
- From: Dragan Milić <email@hidden>
- Date: Wed, 15 May 2019 15:14:24 +0200
> sre 15.05.2019, at 14.24, Thomas Tempelmann wrote:
>
> What you suggest should cover the situation of any path component along the
> full file path being changed, right? I don’t know if in such case resolving
> url’s path is more efficient than comparing strings and asking if an event
> path(s) is a prefix of a dirname(watchedpath).
>
> If you use fileRef URLs, then even if the file gets moved, you can still
> access it. If you use NSURLs based on paths, once the file has been moved,
> you cannot find it any more because it's not at the path where the URL looks
> for it.
I understand all that, I was just discussing why I’d use that approach as well.
To make things more clear, and perhaps it may be interested for others with
similar usage/problems, I’ll give an overview what happens if you monitor
changes of a particular file. Let’s say the full file path is
“/Folder1/Folder2/Folder3/File4” and an event stream is created with
kFSEventStreamCreateFlagFileEvents and kFSEventStreamCreateFlagWatchRoot flags.
Non-sandboxed application:
Case 1: “File4” created in “/Folder1/Folder2/Folder3”:
— eventPath[0] = “/Folder1/Folder2/Folder3/File4”, eventFlags[0]
contain (kFSEventStreamEventFlagItemIsFile & kFSEventStreamEventFlagItemCreated)
Case 2: “File4” modified in “/Folder1/Folder2/Folder3”:
— eventPath[0] = “/Folder1/Folder2/Folder3/File4”, eventFlags[0]
contain (kFSEventStreamEventFlagItemIsFile &
kFSEventStreamEventFlagItemModified)
Case 3: “File4” deleted in “/Folder1/Folder2/Folder3”:
— eventPath[0] = “/Folder1/Folder2/Folder3/File4”, eventFlags[0]
contain (kFSEventStreamEventFlagItemIsFile & kFSEventStreamEventFlagItemRemoved)
Case 4: “File4” renamed to “File5" in “/Folder1/Folder2/Folder3”:
— eventPath[0] = “/Folder1/Folder2/Folder3/File4”, eventFlags[0]
contain (kFSEventStreamEventFlagItemIsFile & kFSEventStreamEventFlagItemRenamed)
— eventPath[1] = “/Folder1/Folder2/Folder3/File5”, eventFlags[1]
contain (kFSEventStreamEventFlagItemIsFile & kFSEventStreamEventFlagItemRenamed)
Case 5: “File4” moved (renamed) outside of "/Folder1/Folder2/Folder3”:
— eventPath[0] = “/Folder1/Folder2/Folder3/File4”, eventFlags[0]
contain (kFSEventStreamEventFlagItemIsFile & kFSEventStreamEventFlagItemRenamed)
Case 6: Any folder along the full path “/Folder1/Folder2/Folder3/File4” (e.g.
“Folder2”) is renamed:
— eventPath[0] = “/Folder1/Folder2/Folder3/File4”, eventFlags[0]
contain ONLY kFSEventStreamEventFlagRootChanged
For a sandboxed application, everything is the same, except that the case 6 is
not detected at all, the event stream stays silent. So, in order to catch the
case 6, I can watch "/Folder1/Folder2/Folder3” instead, but that would catch
only renaming of “Folder3”, hence to catch renaming of “Folder2” I have to
watch “/Folder1/Folder2” and subsequently we come to that I have to watch “/“
and filter event paths myself. So, for changes in cases 1 - 5, I have to do
filtering myself with condition:
for (each i)
{
if ([watchedPath isEqualToString:eventPath[i]])
{
// do process…
break
}
}
For changes in case 6 I can do filtering myself with condition:
for (each i)
{
if ([[watchedPath stringByDeletingLastPathComponent]
hasPrefix:eventPath[i]] && (eventFlags[i] & (kFSEventStreamEventFlagItemIsDir |
kFSEventStreamEventFlagItemRenamed)))
{
// do process…
break
}
}
… or take the approach you suggest:
newPath = [fileReferenceURL path];
if (![newPath isEqualToString:oldPath])
{
oldPath = newPath;
// do process…
}
… and I was just wondering which one would be more efficient. That also depends
on a number of changes on the filesystem, so it’s not deterministic.
-- Dragan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden