File-level filesystem change notification in Mac OS X

I'm using FSEvents APIs to detect file system changes for backup application. Application creates a FSEvent stream on ROOT (`/`) path. Now the problem starts if sombody removes a file via shell with different case/normalization. Let say if folder (/Users/bob) contains a file called `a.txt` and user deletes it with `A.TXT`, under this situation event will generate against path `/Users/bob/A.TXT` rather than `/Users/bob/a.txt`.


At this moment backup application has no clue about the case of deleted file (under HFS+ and APFS). From 10.13 onwards APFS is the default file-system for Mac devices and it preserve the normalization of file. So under APFS problem becomes more complex since application also clueless about the normalization of deleted file. In the developer docs I din’t find details about this. Ideally delete event should preserve the case and normalization of file.


Any insight on this is appreciated.

Replies

IMO a backup application shouldn’t be using the file-level tracking in FSEvents (that is, not use

kFSEventStreamCreateFlagFileEvents
). Rather, stick with directory level events and then compare the directories to calculate the differences. That comparison will have to take into account the different case and normalisation behaviours on the source volume and the destination backup store. This can be quite tricky, especially if the capabilities of the backup store don’t match the capabilities of the source volume.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Unmasking of

kFSEventStreamCreateFlagFileEvents doesn’t serve the purpose since calculation of hierarchy difference leads to increase in CPU, memory and disk IO consumption. Consider a case where directory consist of thousands/millions of files and directories, so single change in immediate child of that directory requires hefty computation.


I observe case and normalization are preserved for operation other than delete. So why behavior is different for file/folder delete event? It seems while accumulating events, paths are getting normalized except this case.