nfs mount point file change does not trigger a re-render of mdbook content

[omac777]

I am running an mdbook server on a machine let's call abbott.

The mdbook contents mystuff are located on an nfs mountpoint let's call frankenstein.

I go to another machine costello and edit /mnt/frankenstein/mystuff/src/ch01-blah.md and save the changes.

BUG: The mdbook server didn't re-render the saved /mnt/frankenstein/mystuff/src/ch01-blah.md file.

EXPECTATIONS: I was expecting the mdbook server to re-render it so that I can view the changes in the web browser.

[wez]

Sorry to say that this will never work in a scalable fashion: there is no provision in NFS for broadcasting change events to clients which means that the only way to get close to something like this would be to build logic that continually walks the full directory structure to poll for changes in a busy loop; that would keep both the client and the server busy and put additional load on the network. It's not a very desirable outcome.

[omac777]

Then may I recommend you at least clarify the constraints in which mdbook users should use this tool? I would recommend that a team of mdbook users working on one book at the very least ssh into the same host where the mdbook server is running.  In the example case I described this was the host called "Abbott".  From there any changes that the team affect on different files will at least be detected by the mdbook server.  The team may still commit their different file changes into a git in this way as well. On Saturday, December 18, 2021, 12:11:28 p.m. EST, Wez Furlong ***@***.***> wrote: Sorry to say that this will never work in a scalable fashion: there is no provision in NFS for broadcasting change events to clients which means that the only way to get close to something like this would be to build logic that continually walks the full directory structure to poll for changes in a busy loop; that would keep both the client and the server busy and put additional load on the network. It's not a very desirable outcome. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: ***@***.***>

[wez]

FWIW, I'm not a maintainer of this project, just an interested user who happens to have experience with file change notification systems reviewing the open issues.