How exactly does Cargo detect file changes?

Question

tl;dr: I want to know what cargo uses to determine whether or not a file has changed to debug a problem I've observed in my build system setup.

Description

I currently have lsyncd setup to mirror project files onto a remote linux machine where I compile code via ENVVARS_HERE=$my_values cargo build. lsyncd's use of rsync w/ the archive flag unfortunately seems to not copy over whatever attribute it is that cargo uses to determine whether or not a file has been edited:

I have a workspace set up:

workspace
+ crateA
  + ...
+ crateB
  + ...

where crateB depends on crateA. Henceforth, 'remote machine' refers to the machine on which cargo is invoked, and 'local machine' refers to a machine editing the code that lsyncd then passes onto the 'remote machine'. I will use 'recently' to refer to any time during which the dependencies of the action being described have not been changed relative to the state being described in a manner I am aware of.

Situation A

Initial state:

• workspace has been copied from the local machine to the remote machine
• lsyncd is not running on the local machine
• crateB has been compiled recently by cargo build on the remote machine

Perform:

• edit source file in crateB on the remote machine
• invoke cargo build on the remote machine

Result:

• crateB is recompiled by cargo on the remote machine

Situation B

Initial state:

• workspace has been copied from the local machine to the remote machine
• lsyncd is running on the local machine (see notes below regarding configuration)
• crateB has been compiled recently by cargo build on the remote machine (see notes regarding timing relative to lsyncd's operation modes)

Perform:

• edit crateB file on local machine
• wait for synchronization to trigger and complete
• invoke cargo build on remote machine

Result:

• crateA compiles on the remote machine, followed by crateB

Notes

• lsyncd was run both with and without archive = true (which to the best of my knowledge sets rsync's archive flag to copy 'most' metadata, where 'most' appears to miss whatever it is that cargo cares about), with no observed change in the results.
• compilation for initial state where lsyncd was present was tested for the following cases with no observed changes in the results: compilation before lsyncd's initial pass, and compilation after lsyncd's initial pass
• the target directory for lsyncd on the remote machine is on a tmpfs filesystem (if that makes some arcane difference)

Question

I want a way to suss out what's going on here, both in this situation with lsyncd and in the future if/when I give up on lsyncd for some other approach that stumbles on a similar problem. Sources regarding cargo on e.g. SO reference the use of timestamps, but there are many kinds of timestamps and which timestamp they refer to is unclear.

What exactly does cargo check for when determining whether or not a file has changed?

Answer 1

So cargo uses fingerprints to track change metadata.

Seems to me from reading the code that it's related to mtime, the modified time; fingerprint::find_stale_file and paths::mtime_recursive.