Bug: Unstable Windows tests for the file tailer

[Skeen]

trafficstars

As stated here: https://github.com/fstab/grok_exporter/pull/95#issuecomment-623672827, the Windows file tailer tests are flakey, and they should be fixed.

I provided a potential explaination of the issue here: https://github.com/fstab/grok_exporter/pull/95#issuecomment-623905441

[fstab]

I agree, we should fix it and not ignore it. Here's an example error message (there are other flaky things on Windows, but this one happens often):

--- FAIL: TestAll (76.82s)
    --- FAIL: TestAll/multiple_log_files,_single_directory(closeFileAfterEachLine,fseventTailer,create,cp) (0.01s)
        fswatcher_test.go:652: C:\Users\appveyor\AppData\Local\Temp\1\grok_exporter617375194\logdir still contains file logfile2.log after mv.

The error comes from fswatcher_test.go#L482-L484.

The test uses different configurations to simulate logrotate configurations. The configuration is shown in (...) next to the test name. In this example the cp option is used, which means that the logfile is not really moved, but rather first copied and then the original is deleted. As the file is still there after that, it means that os.Remove() returned successfully, but didn't really remove the file. On Windows, os.Remove() is implemented using the DeleteFileW function.

Other configurations are flaky as well:

--- FAIL: TestAll (76.99s)
    --- FAIL: TestAll/multiple_log_files,_single_directory(closeFileAfterEachLine,fseventTailer,create,rm) (0.01s)
        fswatcher_test.go:652: C:\Users\appveyor\AppData\Local\Temp\1\grok_exporter609323269\logdir still contains file logfile2.log after mv.

Here the option is mv, meaning that an actual os.Rename() is called, which maps on Windows to the MoveFileExW function.

I'd find it weird if Windows file system operations were asynchronous, but we could try to implement a retry-with-timeout on fswatcher_test.go#L482-L484 to see if that helps.