If the file has already been hashed, it's possible we missed a DELETE event, either because of an unexpected exception in the event loop, or due to an OVERFLOW. In this case, we may receive a CREATE event when the file appears to already exist.
Note that we rely on the suppression of CREATE when new directories are created: we need to traverse the existing directory to notify CREATE for any files that may have existed before we started listening, but some of those files might have been created just after we started listening, leading to duplicate events.
In both of the above situations, we still want to avoid sending a CREATE, because the listener already thinks the file exists. If the hash hasn't changed, the listener is already aware of the state of the file, so it should be safe to suppress the CREATE event. If the content has changed, then we should send a MODIFY to notify the listener that something changed.
If the file has already been hashed, it's possible we missed a
DELETEevent, either because of an unexpected exception in the event loop, or due to anOVERFLOW. In this case, we may receive aCREATEevent when the file appears to already exist.Note that we rely on the suppression of
CREATEwhen new directories are created: we need to traverse the existing directory to notifyCREATEfor any files that may have existed before we started listening, but some of those files might have been created just after we started listening, leading to duplicate events.In both of the above situations, we still want to avoid sending a
CREATE, because the listener already thinks the file exists. If the hash hasn't changed, the listener is already aware of the state of the file, so it should be safe to suppress theCREATEevent. If the content has changed, then we should send aMODIFYto notify the listener that something changed.