There is a discussion that contiguous FSEventStreamEventId can be used to detect the old and new names for kFSEventStreamEventFlagItemRenamed events. This does appear to work in my testing of a basic rename case. However, this seems to break down in the following scenario:
- Monitor directory test_dir for events
- File A exists in test_dir
- From a bash terminal issue the command mv A B;touch C;mv C A in test_dir
This results in the events:
2012-11-06 18:13:01.246 test[45080:1603] event [60095818] [10800] [/Users/tim/test_dir/B]
2012-11-06 18:13:01.248 test[45080:1603] event [60095824] [10900] [/Users/tim/test_dir/C]
2012-11-06 18:13:01.253 test[45080:1603] event [60095825] [10800] [/Users/tim/test_dir/A]
The event bits 0x10800 = "File Renamed" and 0x10900 = "File Created/Renamed"
(from FSEvents.h)
kFSEventStreamEventFlagItemCreated = 0x00000100
kFSEventStreamEventFlagItemRenamed = 0x00000800
kFSEventStreamEventFlagItemIsFile = 0x00010000
It appears that the fact that A was renamed to B is lost in this scenario.
I would expect to have seen an event like 60095817 10800 for A.
Can anyone confirm this behavior and if so does anyone have any ideas on how to handle this limitation without having to maintain a separate representation of the directory contents and rescan/compare the entire directory?
I am testing on OS X 10.8.2.
EDIT: Just found another discussion that indicates this may be a more general issue with multiple renames.
