I’ve been testing FSEventsMBS and the demo programs but it seems to give me the wrong flags on changing files.
Changing a file returns 67584 (=h10800) - which equates to Regular File + Renamed
Renaming a file returns 68608 (=h10C00) - which equates to Regular File + Renamed + meta data change
Deleting a file returns 1) 67584 (=h10800) - as above, plus
2) 83968 (=h14800) - which equates to Regular File + Changed Owner + Renamed
Does anyone else have experience in using these event flags to determine what has happened to the file?
Well, no responses to this one.
The FileEventFlag definitions in the MBS documentation are the same as Apple’s documentation for FSEvents - so presumably the error (or bug) is elsewhere.
I’l have to revert to checking the file using FolderItem.exists and FolderItem.owner - but that won’t differentiate between name changes and file deletions.
FSRefs have been deprecated for a couple of OS versions, Yosemite was the first to start removing FS functionality, if you want to use declares you should use NSURL instead.
I seem to recall that NSWorkspace also has a notification for when files changed, but I haven’t tinkered with it.
I never managed to create a watch folder with NSWorkspaceMBS. It just doesn’t work and triggers nothing.
The two example with the MBS plugins just triggers when files are launched etc…
It would be great if Christian can make an Watch folder example with NSWorkspaceMBS
BTW I am using FSEventMBS for a long time and it is working fine.
FSRefs, especially required for Alias resolving were removed in Yosemite, and if you look through the Apple docs, a lot of FSRef APIs are marked as deprecated.
Heres a link to the Xojo Feedback report <https://xojo.com/issue/36059>
To misquote “W”, there are things we know and things we know we don’t know, but this is one of the things where we don’t know that we don’t know…
I can’t find any references in FSEvents to deprecation, nor to deprecation of FSRef - but then I’m not very familiar with Apple’s documentation.
I’m unable to find anything in NSWorkspaceMBS that deals with file system events.
So at the moment I’ll have to struggle on with FSEventsMBS…maybe Apple doesn’t know that I don’t know.
NSWorkspace notifications are deprecated since 10.6 in favor of FSEvents.
But if FSEvents is not supported for a volume, you need to do scanning manually from time to time.
Are you sure? Isn’t it the other way around?
I just had a look and strangely enough, the NSWorkspace stuff has been marked as depreciated… In favor of FSEvents…
Color me confused… Depreciate APIs that use FSRefs & string paths, in favor of NSURL, then phase out some APIs that use NSURLs in favor of string paths.
Pick one and stick with it please!
FSEvents is not related to FSRef.
It uses paths.
Yes, I agree, very confusing.
Now that it all seems clearer(??) - can anyone address the original question as to why the Flags returned by FSEvents do not seem consistent with the events that caused them?