Directory::onDidChange / File::onDidChange fire twice on file save if file not empty

[izuzak]

From @paulpflug on June 22, 2015 9:58

console.log "watching"
fired = false
entry.onDidChange ->
  console.log "fire"
  unless fired
    fired = true
    console.log "real fire"
    setTimeout (->fired = false), 1000

Output:

watching
## saving empty file
fire
real fire
## saving file with content
fire
real fire
fire

Copied from original issue: atom/atom#7363

[izuzak]

Thanks for the report, @paulpflug -- I was able to reproduce this behavior: saving a non-empty file triggers the callback passed to onDidChange two times.

/cc @kevinsawicki for 👀

[thomasjo]

Saving a file is an atomic operation on most systems, hence the two callback invocations. Whether we should "hide" this or not I don't know. I guess it would be fine to do that as long as it's explicitly documented in the API as a remark or some such.

[mnquintana]

Saving a file is an atomic operation on most systems

Hmm, so in this case do you mean that the same callback is invoked once when the file starts being saved, and once when the file is finished being saved?

[thomasjo]

An atomic save consists of (1) saving the contents to a temporary file, then (2) overwriting the target file with the temporary file. Step 2 is usually done as a delete + rename.

[paulpflug]

I think, the easiest way would be to pass the change type as an argument to the callback? That would be super handy. I stumbled upon this missing feature already in #6875 and #73

[thomasjo]

@paulpflug I think that makes a lot of sense 👍

[maecky]

Is there any update or workaround on this "issue"?

[danielbayley]

+1… I just ran into this while trying to figure out why my package was throwing duplicate notifications.

If it must remain the case that it fires twice due to the atomic operation, then I would second @paulpflug's suggestion of passing back a 'change type' argument.

Also maybe a duplicate of #50?