- NoteRename is triggered only on parent directory, not on it's
contents. Now rename events are generated in this case.
- Rewrite old disabled tests to new framework.
The race mentioned in the issue is artificial for real applications, as
Close is never called - it was introduced only for test purposes. It
makes little sense for creating overhead for FSEvents watcher
implementation if rearranging the order of actions can dodge the issue.
Fixes#74.
By default test dumps temporary directory tree in testdata directory.
In order to change the default behaviour to e.g. dump the tree to
C:\Windows\Temp, set:
% set NOTIFY_TMP=C:\Windows\Temp\notify
FSEvents tends to send squashed old and new flags for an event. E.g.
for the following filesystem operations:
~ $ echo > file # Create|Write -> Create|Write
~ $ echo > file # Create|Write|InodeMetaMod -> Write|InodeMetaMod
FSEvents sends accordingly "Create|Write" and "Create|Write|InodeMetaMod"
events, even though "Create" event shouldn't be present in the latter
set.
There're two changes that, proved empirically, improves the accuracy
of reported events:
- the sinceWhen for FSEventsStreamCreate is change from the Now const
to quasi-recent event id value; the watcher then ignores all
received events until it receive HistoryDone one (flushing?)
- improved heuristics (+ doc) for striping old events from sets
And no, increasing latency does not force FSEvents to send old events,
besides making the tests extremely slow.
Since FSEvents tends to send unrelated, historical flags altogether
with the actual event, its watcher implementation needs to bookkeep
them and filter out duplicated events before dispatching to the user.
The problem arises of the first event for a given path is Write -
FSEvents sends Create+Write but watcher has no knowledge what was the
real previous state of the event, that's why it will also dispatch
Create event to the user. This should be documented (#48) or even better
fixed.
That's why in test-cases we begin with dummy Create's to "initialize"
state of the history bookkeeping map. Lame, I know.
Set of chans used in ExpectTreeEvents and ExpectTreeEvents tests is
expected to received exactly one unique event per each chan. Current
version could receive duplicated events and tests would not fail, even
though that condition is invalid.
Simon Frei
DiSiqueira
Rafal Jeczalik
Paweł Błaszczyk
Pawel Knap