Restarting before file changes are complete

[Onfire7]

I run node through a SSH connection to my web server, and FTP upload file updates.
The issue is that most of the time, supervisor will restart node before the file is finished uploading.
It's not a huge deal, but it does make it more difficult to look at debugging information from before it was restarted, and it prevents me from using no-restart-on errors.

It would be nice to have a check that the file has stopped changing.
Or to be able to configure a delay before restarting node after detecting a change.

[iangreenleaf]

Yeah, I can see how this would happen. Probably FTP writes to the file in chunks, or writes to one file and then another - the end result being that node sees a file change notification before FTP has finished its work.

Unfortunately, I don't think there's any way to know when a file "has stopped changing". All node knows is that the file changed just now, and who knows if it will change again in the future.

The delay might be doable - we're actually already waiting for a very short delay (100ms or something) to avoid firing multiple times for git checkouts and CoffeeScript compilations and the like. So if that was configurable you could just set it to something exceptionally long like 30s.

My only qualm about adding that option is increasing code and API complexity for something that's a bit of an edge case. Not saying it's out of the question, just that I want to keep supervisor reasonably lean, which means I'm hesitant to add features unless they're valuable to more than just a couple people.

[Onfire7]

The only way to know if it's done, is to have a loop after detecting the change, that will keep checking it until it stops changing. Kinda undesirable, which is why I threw the bit about the configurable delay.

I kinda figured it would be an edge case, but my thought was that it's the kind of thing that would be annoying enough to be an issue, but not so much that anyone would say anything about it.

[iangreenleaf]

Ah, I see what you had in mind. Yeah, I think a configurable delay would be the way to go. I may leave this open for a bit and see if anyone else mentions this as a problem. I'll edit the title to a bit more descriptive, too.