File changes can be missed if they occur within 1 second

[njx]

On the Mac, if a file is modified multiple times within the same second, we don't always end up with the latest version of the file in open documents in Brackets, because the resolution of timestamps on the Mac is 1s.

I run into this regularly when rebasing, because the process of rebasing multiple commits leads to the same file being rewritten multiple times in quick succession. (It's a little hard to come up with a brief recipe for reproducing this, but I can make one up if it would help.)

It seems like there are two levels at which this could occur:

1. In the FileSystem layer, we ignore changes if the cached stat's mtime is the same as the file's current mtime.
2. In FileSyncManager, we ignore changes if the document's timestamp is the same as the file's mtime.

We could fix (1) by actually re-reading the content when we get a change event and seeing if it changed in order to determine whether to dispatch a change event higher up. Obviously that could be a performance hit, but since in most cases a change event means the file actually did change, it seems like this shouldn't be a huge extra impact.

We could fix (2) by making it so that when FileSyncManager.findExternalChanges() is called as the result of a filesystem change event, we pass in a list of the files that were changed. For those files, FSM could ignore the timestamps and always re-read the files.

(Interestingly, when I reproduce this in the rebase scenario, it seems sometimes like (2) fails but not (1) - i.e., the file is not correct in the open document, but if I close and reopen it I get the correct contents. I'm not sure why that would happen, so there might be some other behavior I'm not aware of here.)

[njx]

@peterflynn @gruehle Any thoughts?

[gruehle]

We could also add a size check in addition to the mtime check. This would be very cheap since the stat object already has a size field. For (2), this would require remembering the size along with the timestamp.

This would catch more cases, but would still get fooled if there are multiple changes without a size change.

Re-reading the contents could get very expensive on folder or wholesale changes.

[njx]

@gruehle Yes, but it seems like if we get a specific file change, we probably need to re-read it anyway. I do remember, though, that on the Mac we tend to get directory changes for the parent instead of individual file changes, at least in some cases. It would be good to understand when/how often that happens.

[njx]

Medium priority to @peterflynn

[njx]

Marking Brackets 1.0