I wasn't previously familiar with the --omit-dir-times option. As you discovered, the low-level parts of rsync_bpc don't 100% faithfully mimic the native linux system calls. In particular, the mkdir() in rsync_bpc doesn't set the mtime, since rsync updates it later (assuming --omit-dir-times is not specified).
It would be a one-line change to set the mtime to the current time in bpc_mkdir() in bpc_sysCalls.c. However, I don't think it makes sense to "fix" it, since a backup shouldn't add metadata that changes each time you backup some data that hasn't changed. Craig On Fri, May 22, 2020 at 8:17 PM Michael Stowe < michael.st...@member.mensa.org> wrote: > On 2020-05-22 16:52, backu...@kosowsky.org wrote: > > Michael Stowe wrote at about 23:46:54 +0000 on Friday, May 22, 2020: > > > On 2020-05-22 16:19, backu...@kosowsky.org wrote: > > > > Michael Stowe wrote at about 22:24:13 +0000 on Friday, May 22, > > 2020: > > > > > On 2020-05-22 09:15, backu...@kosowsky.org wrote: > > > > > What it does is omit directories from the modification times > > that it > > > > > sets. In other words, you're telling it not to set the times > > on > > > > > directories it copies. The beginning of the epoch is pretty > > > > reasonable > > > > > for directories which have no specific time set. > > > > > > > > > > > > > Actually, at least the manpage is unclear. > > > > And *differs* from the default behavior of native rsync (at lesat > > on > > > > Ubuntu) that sets the dir time to the current time -- which is > > more > > > > reasonable than some arbitrary epoch = 0 time. > > > > > > > > That is what I would have expected and I believe should be the > > default > > > > behavior... > > > > > > > > > This option has no implications for which directories are > > selected > > > > to be > > > > > copied. > > > > > > Unset is unset, it's not the option to use if you want the directory > > > modification time set. > > > > Regardless, behavior should be consistent with normal rsync... > > > > If you can show me a standard *nix version of rsync that uses Epoch as > > the default then I would retract my point... but otherwise Epoch is > > totally arbitrary and illogical... while at least the current time has > > a good rationale... Choosing 1/1/1970 not so much... > > It's not that "epoch is the default" it's that that's what a timestamp > of 0 is. When you tell rsync not to set the timestamps, it doesn't. > > If you want to touch the directories and update their timestamps to the > current time, you can do that, but it's an odd thing to expect rsync to > take care of for you when you explicitly tell it not to. > > > _______________________________________________ > BackupPC-users mailing list > BackupPC-users@lists.sourceforge.net > List: https://lists.sourceforge.net/lists/listinfo/backuppc-users > Wiki: http://backuppc.wiki.sourceforge.net > Project: http://backuppc.sourceforge.net/ >
_______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
