I have recently implemented hashbackup to replace CrashplanPRO but believe that hashbackup has just made the problem more visible. I had seen Crashplan backing up files more than once but never investigated why mainly because the size wasn't affecting me.

 

Anyway, I'm seeing files that have not been changed in years having their modified/changed times altered. e.g. I do a hashbackup, then run it again a few hours later and something's modified some files e.g. a particularly random one just now:

 

~# stat "/mnt/user/store/manuals and drivers/A8N-SLI Premium Drivers/15.23_nforce_winxp32_international_whql.exe"
  File: /mnt/user/store/manuals and drivers/A8N-SLI Premium Drivers/15.23_nforce_winxp32_international_whql.exe
  Size: 53370976        Blocks: 104248     IO Block: 4096   regular file
Device: 2fh/47d Inode: 648799821402998927  Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (   99/  nobody)   Gid: (  100/   users)
Access: 2017-04-04 06:21:53.417766486 +1000
Modify: 2008-10-05 09:03:49.000000000 +1000
Change: 2021-10-10 17:53:26.528479637 +1000
 Birth: -

 

There's no way I touched it just now. That's about 20 minutes ago. Whole chunks (not every file in a folder though) randomly have their change time altered and the backup program picks it up.

 

Could the file integrity plugin do anything like this? I've set it up recently but pretty sure the repeated backups were happening long before that.

 

If a file is not being actually changed how else could this be happening?

 

All disk file systems are xfs. Not entirely sure what else would be relevant. Nothing in syslog at the change time.

 

Checking the direct /mnt/diskx/... file shows the same info but with the birth field entered (seems just before the access time)

I dont know for sure but i would suspect it is the file integrity plugin. The "Changed" time reported by stat is the last time that file metadata was changed (most docs list permissions as an example of metadata). The file integrity plugin stores its hash value in the extended attributes. What i dont know is if extended attributes are considred metadata in this instance, but i would suspect so. 

It did appear to be the file integrity plugin as updating one of the file date attributes resulting in hashbackup backing them up again. I've stopped the plugin for now.

The dynamix file integrity plugin does not touch any file itself, it purely operates on extended attributes.

The file modification time is never altered by the plugin.

 

The dynamix file integrity plugin does not touch any file itself, it purely operates on extended attributes.
The file modification time is never altered by the plugin.
 

Right but the Change time is being updated (see original post) which appears to be what hashbackup is seeing.