Bug 760131

I have similar issue, but it detects changed and unchanged files as removals and additions

Created attachment 540949 [details]
snapshots - unchanged/changed files detected as additions and removals

In may case this is/was a pinned snapshot which received the new file after pinning and thus all modifications to that file after pinning.
After unpinning the definition, the change-detection works as it should.

yes, this was a pinned snapshot. I have unpinned it, did some changes, detected it and it still shows unchanged files as added and removed. I guess it deserves separate bz

After discussing the issue with Heiko, I have determined that this is not a bug and is the correct, intended behavior. The file was being reported as new multiple times because it was getting changed multiple times. I will explain why this is the correct behavior. 

With a pinned definition, the agent is always comparing files (on the file system) against the same pinned snapshot.  In this case Heiko added /etc/new_file.txt, and it is not part of the pinned snapshot. The agent correctly reported it as a new file. Suppose the SHA for new_file.txt was a1b2c3. After the agent reported the drift, Heiko modified the file, resulting in a different SHA, call it a4b5c6. When the agent runs drift detection again, it will once again see that /etc/new_file.txt is not in the pinned snapshot. A very important thing to understand here is that even if the file was not modified such that it still had the original SHA of a1b2c3, the agent would still detect it as a new file. This is because the file is not part of the pinned snapshot. 

We do not want the agent to keep reporting the same drift over and over. If the SHA has not changed, but the definition is out of compliance, the agent should not keep reporting the same drift; therefore, there is logic that kicks in to determine if the drift change set is a repeat. In Heiko's case, it was not repeat drift. In snapshot one, the agent detected a new file with SHA a1b2c3. In snapshot two, the agent detects the same file with a different SHA of a4b5c6; so, the agent again reports drift where the change is a new file.

In discussing this, Heiko asked an excellent question which is this. How come the agent reports /etc/new_file.txt as new in snapshot two instead of as modified? The reason is because comparisons are always made relative to the pinned snapshot. And with respect to the pinned snapshot, /etc/new_file.txt will *always* be reported as new because it is not included in the pinned snapshot. If we want it to be reported as modified then we need to re-pin the definition such that /etc/new_file.txt is included.