Watch mode does not work when the file is momentarily deleted then re-created

[user202729]

Version of Marp Tool

@marp-team/marp-cli v2.2.2 (w/ @marp-team/marp-core v3.4.0)

Operating System

Linux

Environment

• OS version: Linux archlinux 6.0.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 16 Nov 2022 17:01:17 +0000 x86_64 GNU/Linux
• Node.js version (Marpit / Marp Core/ Marp CLI): v19.1.0

How to reproduce

1. Create a Markdown file on hard drive (not tmpfs)
2. Edit the file with vim and marp --watch compile that file
3. Save the file once. The file is correctly recompiled.
4. Edit something, save the file again. It's no longer recompiled.

Expected behavior

That it recompiles every time the file is edited.

Actual behavior

See "how to reproduce" section.

Additional information

As mentioned above, I suspect the cause is that vim momentarily delete the file then re-create it, which breaks the watching logic of Marp.

Using something such as echo 1 > solution.md works fine.

[yhatt]

I've tested steps for reproduce on Arch Linux, but cannot reproduce in my environment.
Linux archlinux 6.1.6-arch1-3 #1 SMP PREEMPT_DYNAMIC Mon, 16 Jan 2023 12:51:23 +0000 x86_64 GNU/Linux

I suspect the cause is that vim momentarily delete the file then re-create it, which breaks the watching logic of Marp.

I could not confirm that too. When a watching file is deleted and re-created, my Marp CLI have watched the created file again and generate new HTML.

$ touch test.md
$ marp -w test.md &
[  INFO ] Converting 1 markdown...
[  INFO ] test.md => test.html
[  INFO ] [Watch mode] Start watching...
$ rm test.md
$ touch test.md
[  INFO ] test.md => test.html

As described in #267 (comment), increasing the amount of inotify watchers may resolve the watcher's stop.
https://github.com/guard/listen/blob/master/README.md#increasing-the-amount-of-inotify-watchers

Appendix: https://gist.github.com/coenraadhuman/fa7345e95a9b4dea851dbe9e8f011470

[user202729]

Increasing the amount of inotify watchers doesn't help.

I think it's some race condition, I try using this C program to modify the file:

#include<stdio.h>
#include<stdlib.h>
#include <unistd.h>

int main(){
	char buffer[4096];
	
	/*
	int fd = open("/home/user202729/solution.md", O_RDONLY);
	int numRead = read(fd, buffer, 4096);
	close(fd);
	*/

	// use fopen
	FILE *fp = fopen("/home/user202729/solution.md", "r");
	int numRead = fread(buffer, 1, 4096, fp);
	fclose(fp);

	unlink("/home/user202729/solution.md");

	//sleep(1);  // if this is uncommented, the bug does not happen

	fp = fopen("/home/user202729/solution.md", "w");
	++buffer[0];
	fwrite(buffer, 1, numRead, fp);
	fclose(fp);

}

apart from the first time the file is modified, marp does not detect the change.

But if I uncomment the sleep(1) line, marp correctly updates every time.

So I think the unlink and write must happen in quick succession for the bug to be triggered. (while bash is not fast enough?)

Not sure why you cannot reproduce it with your vim version.

The bug is indeed infrequent, I cannot completely reliably reproduce it.

[yhatt]

Marp just uses chokidar to watch file(s), so in reality Marp may not be able to do anything.
https://github.com/marp-team/marp-cli/blob/main/src/watcher.ts

Consider to report that into chokidar issue tracker.

FYI chokidar recognizes "atomic writing" caused from vim by Marp CLI's default setting, and normalize a bunch of deletion and creation to just an event of the file change.

[yhatt]

Close for cleaning up Marp CLI issue tracker. Again: Please report this to chokidar, a file watcher Marp CLI is using.