Issue Migrator re-sync modifies change time of ALL mailbox files on target server instead of just those that need syncing

[philbit]

Dear all,

The migration & transfer tool and the possibility to re-sync after an initial migration are great. I am currently using it to configure and test a new server while the old one is still running, doing re-syncs once in a while to keep the new server up-to-date, thoroughly check some things on it manually, and to keep the amount of data small that will need to be transferred on the final re-sync before going live with the new server.

While doing this, I discovered an issue that might be easy to fix: When doing a re-sync, ALL files under /var/qmail/mailnames/{domainname} get a new "change time" as reported by stat, even if they (and all their stat attributes) are not modified. I suspect the reason is a command like

chown -R popuser:popuser /var/qmail/mailnames/{domainname}

(or a similar blanket command) that is run by the migration re-sync at the end of the transfer, which is a no-op for many files (if, e.g., for the command above, a file is already owned by the correct user) but resets all the change times to the current time.

This behavior is problematic if the change time is used to detect changed files for incremental backup purposes (as is also done by the native Plesk backup), since the complete mailboxes will be backed up after every migration re-sync. This could be easily avoided if the chown (or whatever causes the updated change time) is only applied to files for which it is necessary.

Just for curiosity: For the website data under /var/www/vhost/{domainname}, the issue is not present, so apparently no blanket command with the side effect of updating change time is executed. So the behavior is also slightly inconsistent.

Best regards,
Philip

 

[Bitpalast]

I remember a similar discussion here where a restore has reset the datetime records of the email files, too, to the current date, which in turn caused mail client software to download mails repeatedly. Migrator and backup manager are practically the same thing, I thought that this issue should have been solved by now, but obviously it's not been solved. It would be nice to know why not.

 

[philbit]

Ah, that's interesting. Of course, that would indeed be even worse. But, fortunately, the "modified" time is not altered by the migrator upon re-sync (so at least that part seems to have been resolved).

So just to be clear: The "modify" time is correctly synced from the source to the target and not altered upon re-sync. Only the "change" time is altered upon re-sync, probably by explicitly setting some file attribute to a value it already has, thus not actually doing anything. I think it's easy to miss this since it wouldn't have any effect for the original migration, only for a re-sync, and there it only becomes obvious if the "change" time is used for anything.

If I have time, I might dig a bit and see if this by any chance happens in a script that I can examine / modify for testing purposes.