Re: [BackupPC-users] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch
On 2020-05-23 23:47, backu...@kosowsky.org wrote: 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: --ignore-dir-times and --omit-dir-times are two different options ___ 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/
Re: [BackupPC-users] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch
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 < > michael.st...@member.mensa.org> wrote: > > > On 2020-05-22 16:52, backu...@kosowsky.org wrote: > > > Michael Stowe wrote at about 23:46:54 + on Friday, May 22, 2020: > > > > On 2020-05-22 16:19, backu...@kosowsky.org wrote: > > > > > Michael Stowe wrote at about 22:24:13 + 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:
Re: [BackupPC-users] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch
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 + on Friday, May 22, 2020: > > > On 2020-05-22 16:19, backu...@kosowsky.org wrote: > > > > Michael Stowe wrote at about 22:24:13 + 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/
Re: [BackupPC-users] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch
On 2020-05-22 16:52, backu...@kosowsky.org wrote: Michael Stowe wrote at about 23:46:54 + on Friday, May 22, 2020: > On 2020-05-22 16:19, backu...@kosowsky.org wrote: > > Michael Stowe wrote at about 22:24:13 + 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/
Re: [BackupPC-users] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch
Michael Stowe wrote at about 23:46:54 + on Friday, May 22, 2020: > On 2020-05-22 16:19, backu...@kosowsky.org wrote: > > Michael Stowe wrote at about 22:24:13 + 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... ___ 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/
Re: [BackupPC-users] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch
On 2020-05-22 16:19, backu...@kosowsky.org wrote: Michael Stowe wrote at about 22:24:13 + 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. ___ 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/
Re: [BackupPC-users] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch
Michael Stowe wrote at about 22:24:13 + on Friday, May 22, 2020:
> On 2020-05-22 09:15, backu...@kosowsky.org wrote:
> > If I add '--omit-dir-times' to $Conf{RsyncArgsExtra}, then the backups
> > set all the directory dates to the beginning of the Epoch.
> >
> > For example
> > drwxr-xr-x 3 backuppc www-data 1024 Dec 31 1969 pc/
> >
> > (note this is 1/1/70 00:00:00 GMT)
> >
> > This is inconsistent with normal rsync wich just uses --omit-dir-times
> > to omit directories from --times when looking for *changes*
> >
> > I was expecting and would have liked the normal behavior of
> > --omit-dir-times to speed up backups...
> >
> > Is this a bug???
>
> No, it's expected behavior, you seem to have misunderstood what this
> rsync option does.
>
> 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.
___
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/
Re: [BackupPC-users] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch
On 2020-05-22 09:15, backu...@kosowsky.org wrote:
If I add '--omit-dir-times' to $Conf{RsyncArgsExtra}, then the backups
set all the directory dates to the beginning of the Epoch.
For example
drwxr-xr-x 3 backuppc www-data 1024 Dec 31 1969 pc/
(note this is 1/1/70 00:00:00 GMT)
This is inconsistent with normal rsync wich just uses --omit-dir-times
to omit directories from --times when looking for *changes*
I was expecting and would have liked the normal behavior of
--omit-dir-times to speed up backups...
Is this a bug???
No, it's expected behavior, you seem to have misunderstood what this
rsync option does.
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.
This option has no implications for which directories are selected to be
copied.
___
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] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch
If I add '--omit-dir-times' to $Conf{RsyncArgsExtra}, then the backups
set all the directory dates to the beginning of the Epoch.
For example
drwxr-xr-x 3 backuppc www-data 1024 Dec 31 1969 pc/
(note this is 1/1/70 00:00:00 GMT)
This is inconsistent with normal rsync wich just uses --omit-dir-times
to omit directories from --times when looking for *changes*
I was expecting and would have liked the normal behavior of
--omit-dir-times to speed up backups...
Is this a bug???
___
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/
