`cargo watch` triggering on file that hasn't changed (only read)

[edmorley]

Hi! Thank you for a great tool :-)

I'm currently experiencing cargo watch -x test looping indefinitely, with --why reporting that the cause is a file that hasn't been modified (the file is read during cargo test and copied to a temp dir, but the original isn't modified itself).

I was wondering if you might have some insight?

Steps to reproduce:

1. git clone https://github.com/Malax/libcnb.rs (currently at fd1686f8d0fe07aca5e0b9592fbdee1919591fdb)
2. cd libcnb.rs/examples/example-02-ruby-sample/
3. cargo watch -x test --why

Expected:

Test command is run only once, and waits for next modification to the project source before being re-run.

Actual:

Test command is run repeatedly in a loop.

Output says:

2022-02-02T23:27:19.085+00:00 - INFO - Paths updated: [PathOp { path: "/Users/emorley/src/libcnb.rs/examples/example-02-ruby-sample/test-fixtures/simple-ruby-app/app.rb", op: Some((empty)), cookie: None }, PathOp { path: "/Users/emorley/src/libcnb.rs/examples/example-02-ruby-sample/test-fixtures/simple-ruby-app/Gemfile", op: Some((empty)), cookie: None }, PathOp { path: "/Users/emorley/src/libcnb.rs/examples/example-02-ruby-sample/test-fixtures/simple-ruby-app/Gemfile.lock", op: Some((empty)), cookie: None }]

Stating the files before/after shows nothing has changed:

$ stat test-fixtures/simple-ruby-app/app.rb  File: test-fixtures/simple-ruby-app/app.rb
  Size: 150             Blocks: 8          IO Block: 4096   regular file
Device: 1,8     Inode: 112878460   Links: 1
Access: (0644/-rw-r--r--)  Uid: (  503/ emorley)   Gid: (   20/   staff)
Access: 2022-02-02 14:49:13.822279666 +0000
Modify: 2022-02-02 14:49:13.762440366 +0000
Change: 2022-02-02 14:49:13.762440366 +0000
 Birth: 2022-02-02 14:49:13.760673662 +0000

$ cargo watch -x test --why
...
<Ctrl+C>

$ stat test-fixtures/simple-ruby-app/app.rb  File: test-fixtures/simple-ruby-app/app.rb
  Size: 150             Blocks: 8          IO Block: 4096   regular file
Device: 1,8     Inode: 112878460   Links: 1
Access: (0644/-rw-r--r--)  Uid: (  503/ emorley)   Gid: (   20/   staff)
Access: 2022-02-02 14:49:13.822279666 +0000
Modify: 2022-02-02 14:49:13.762440366 +0000
Change: 2022-02-02 14:49:13.762440366 +0000
 Birth: 2022-02-02 14:49:13.760673662 +0000

During the test setup, the files in question are copied to a temporary directory here using fs_extra::dir::copy():
https://github.com/Malax/libcnb.rs/blob/fd1686f8d0fe07aca5e0b9592fbdee1919591fdb/libcnb-test/src/app.rs#L5-L21

...but the target directory is in TMP and so not watched, and the source file was never modified.

Additional information

Cargo watch was installed using cargo install cargo-watch (I reinstalled just now using --force to ensure it was recently compiled, given not using --locked).

Versions:

$ rustc --version
rustc 1.59.0-beta.5 (28c8a34e1 2022-01-27)
$ cargo watch --version
cargo-watch 8.1.1

(though this also repros on Rust stable)

This is on macOS 12.2.

[passcod]

I can't really tell. The macos infrastructure for for changes used in cargo watch so far (it's due to change next version) is a black box.

However, from knowledge of how other platforms work, for example inotify on Linux, it's possible that a mere file read access is triggering the change.

[passcod]

Is the lockfile changing?

[edmorley]

Thank you for replying :-)

The workspace Cargo.lock is up to date, checked into the repo (not in .gitignore) and the output from stat doesn't change after running cargo test. It's also in the directories above the working directory in the steps to reproduce (so presumably not watched), and wasn't mentioned in the --why output.

[passcod]

No, I mean in the output you gave, there's --why entries for the gemfile and gemfile.lock

[schneems]

No, I mean in the output you gave, there's --why entries for the gemfile and gemfile.lock

In those tests Gemfile and Gemfile.lock are not modified

Here's another output with the same thing happening (repo not yet open sourced).

$ cargo watch -x test --why  
[Running 'cargo test']
    Finished test [unoptimized + debuginfo] target(s) in 0.13s
     Running unittests (target/debug/deps/procfile_buildpack-202d655ed7e5c570)

running 16 tests
test launch::test::test_no_processes ... ok
test procfile::tests::test_empty_parse_procfile ... ok
test procfile::tests::test_cannot_parse_procfile ... ok
test procfile::tests::test_missing_name_parse_procfile ... ok
test procfile::tests::test_missing_command_parse_procfile ... ok
test tests::test_empty_names_from_processes ... ok
test procfile::tests::test_valid_parse_procfile ... ok
test procfile::tests::test_multiple_valid_parse_procfile ... ok
test tests::test_valid_process_names_from_processes ... ok
test tests::test_missing_procfile_detect ... ok
test tests::test_valid_detect ... ok
test launch::test::test_single_non_web_process ... ok
test launch::test::test_single_web_process ... ok
test launch::test::test_web_and_additional_process ... ok
test launch::test::test_multiple_non_web_processes ... ok
test launch::test::test_process_order ... ok

test result: ok. 16 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests/integration_test.rs (target/debug/deps/integration_test-b6d324553c0598e7)

running 1 test
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
2022-02-02T20:03:19.123-06:00 - INFO - Paths updated: [PathOp { path: "/Users/rschneeman/Documents/projects/work/procfile-cnb-rust/tests/fixtures/app_with_procfile/Procfile", op: Some((empty)), cookie: None }, PathOp { path: "/Users/rschneeman/Documents/projects/work/procfile-cnb-rust/buildpack.toml", op: Some((empty)), cookie: None }]
[Running 'cargo test']
    Finished test [unoptimized + debuginfo] target(s) in 0.15s
     Running unittests (target/debug/deps/procfile_buildpack-202d655ed7e5c570)

running 16 tests
test launch::test::test_no_processes ... ok
test procfile::tests::test_empty_parse_procfile ... ok
test tests::test_empty_names_from_processes ... ok
test procfile::tests::test_cannot_parse_procfile ... ok
test procfile::tests::test_valid_parse_procfile ... ok
test procfile::tests::test_missing_name_parse_procfile ... ok
test procfile::tests::test_multiple_valid_parse_procfile ... ok
test procfile::tests::test_missing_command_parse_procfile ... ok
test tests::test_valid_process_names_from_processes ... ok
test tests::test_missing_procfile_detect ... ok
test tests::test_valid_detect ... ok
test launch::test::test_single_web_process ... ok
test launch::test::test_single_non_web_process ... ok
test launch::test::test_web_and_additional_process ... ok
test launch::test::test_multiple_non_web_processes ... ok
test launch::test::test_process_order ... ok

test result: ok. 16 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests/integration_test.rs (target/debug/deps/integration_test-b6d324553c0598e7)

running 1 test
    Finished dev [unoptimized + debuginfo] target(s) in 0.10s
2022-02-02T20:03:20.825-06:00 - INFO - Paths updated: [PathOp { path: "/Users/rschneeman/Documents/projects/work/procfile-cnb-rust/tests/fixtures/app_with_procfile/Procfile", op: Some((empty)), cookie: None }, PathOp { path: "/Users/rschneeman/Documents/projects/work/procfile-cnb-rust/buildpack.toml", op: Some((empty)), cookie: None }]
[Running 'cargo test']
    Finished test [unoptimized + debuginfo] target(s) in 0.13s
     Running unittests (target/debug/deps/procfile_buildpack-202d655ed7e5c570)

In this case it's saying:

2022-02-02T20:03:19.123-06:00 - INFO - Paths updated: [PathOp { path: "/Users/rschneeman/Documents/projects/work/procfile-cnb-rust/tests/fixtures/app_with_procfile/Procfile", op: Some((empty)), cookie: None }, PathOp { path: "/Users/rschneeman/Documents/projects/work/procfile-cnb-rust/buildpack.toml", op: Some((empty)), cookie: None }]

We're not modifying the Procfile or the buildpack.toml, though as Ed has mentioned they're being copied to a different directory (outside of the current dir, shouldn't trigger cargo watch).

[passcod]

That will probably need a bit of tweaking, but could you use the latest watchexec and see if it's an issue?

$ watchexec --print-events -- cargo test

Also any chance to run on e.g. Linux?

Want to clarify if it's an issue with FSEvents (macos, cargo watch <=8 only) or with cargo watch itself.

[edmorley]

Ah so it doesn't reproduce if I use watchexec v1.18.5 (using the pre-built binaries via brew install watchexec), and run watchexec --print-events -- cargo test instead of step 3, in the OP's steps to reproduce.

Thank you for the suggestion to try that :-)

[passcod]

Right, so it's an FSEvents thing. Unfortunately I can't really mitigate that. However, it will be fixed next release, when upstream watchexec is used here: the backend changes away from FSEvent to the more precise/appropriate kqueue.