Regarding your comment:
> 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.
Actually, the whole point of --ignore-dir-times is that the dir mod
time is not changed each time you rsync.
Behavior is as follows:
1. When created, the mod time is set to 'rsync' run time
2. This mod time is *not* changed on subsequent 'rsyncs' unless a
change to the directory contents occurs in which case the
directory timestamp is updated to the *current* time
Indeed, one reason to use --ignore-dir-times is to avoid changing the
mod time every time the directory mod time changes.
This is different from the absence of --times that changes the mod time of
files/links/devices to the current time on every rsync since the files
show up as changed (unless you also use --ignore-times)
This behavior can be verified by using rsync.
Also, it can be gleaned from the following pulled from the man pages:
o A t means the modification time is different and is being
updated to the sender’s value (requires --times). An
alternate value of T means that the modification time will
be set to the transfer time, which happens when a
file/symlink/device is updated without --times and when a
symlink is changed and the receiver can’t set its time.
(Note: when using an rsync 3.0.0 client, you might see the
s flag combined with t instead of the proper T flag for
this time-setting failure.)
Craig Barratt wrote at about 18:34:54 -0700 on Saturday, May 23, 2020:
> 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 <
> [email protected]> wrote:
>
> > On 2020-05-22 16:52, [email protected] wrote:
> > > Michael Stowe wrote at about 23:46:54 +0000 on Friday, May 22, 2020:
> > > > On 2020-05-22 16:19, [email protected] wrote:
> > > > > Michael Stowe wrote at about 22:24:13 +0000 on Friday, May 22,
> > > 2020:
> > > > > > On 2020-05-22 09:15, [email protected] 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
> > [email protected]
> > List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> > Wiki: http://backuppc.wiki.sourceforge.net
> > Project: http://backuppc.sourceforge.net/
> >
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
