Pause tailing the file

[JYone3A]

Hi,

I wonder if it would be possible to include a pause and resume method.

I am assuming that it should be fairly simple:

pause() {
  if (this[kQuitting]) return
  
  clearTimeout(this[kPollTimer])
  this.paused = true
}

async resume() {
  if (!this.paused) return
  
  this[kStartPos] = null
  this.paused = false
  
  this._pollFileForChanges()
}

Side quesion: Is the assumption correct that I always (also for the pause/resume case above) get a flush event before any data, therefore I am always able to get lastReadPosition first (I need the exact start byte for each chunk).

[jakedipity]

@JYone3A The TailFile class extends node's steam.Readable which already implements pause() and resume() functions. Are those functions working for you?

As for your side question, flush events happen after one or more data events and you can see it in the function _readChunks(): the flush event is emitted after this.push() is called.

[JYone3A]

Thanks. I just tried this. I still get the 'flush' events when I use pause(), so internally the polling still seems to run. Data events do not come in any more, but I assume tail-file still does all the work.

I impemented the functions in my fork (called them unwatch and rewatch for now, as I also stumbled upon the fact that pause and resume are already there), it pretty much works as written above.

With respect to flush, its also triggered in _pollFileForChanges(), if no changes where found. I am now very sure that there's always a first 'flush' event, as _streamFileChanges() is only called from the above function, and if its not called because no change was found - or it was the first execution of this function - flush is triggered.

[jakedipity]

Ah okay, this seems consistent with Node's documentation; pause puts a stream into a non-flowing state where data is still buffered but needs to be collected explicitly with a call to stream.read(). Eventually the internal buffer will hit the highWatermark (default 64KiB) which should cause flush events to stop.

I like creating separate functions to control the internal polling mechanism. This aligns well with the existing start and quit functions. @JYone3A If you put up a PR with appropriate testing we can take a look!

[JYone3A]

I created a pull request. I'm not sure about the method names (unwatch/rewatch).

Also, maybe the unwatch method should call await this._pollFileForChanges() one last time at the end? (it should probably still not be an asynchronous function but instead return the promise returned by _pollFileForChanges)