weird rsync behaviour after switch to 15

[R2-D2]

Local machine just upgraded from 14.2 to 15.0. Rsync package version 3.2.3-x86_64-4.

Remote machine still on 14.2,
rsync package version 3.1.3-x86_64-1_slack14.2.

I have a directory on the remote machine that has always been backed up locally
with rsync. After switching to 15 every single file "is newer" on the local
machine, where it has always been "is uptodate".

$ rsync -arvvtu --delete ***@remote:/remotedir/ /localdir

The files are identical, their timestamps are identical to the nanosecond. Any
clue? Idiosyncrasies between different rsync versions?

Thanks.

[John Forkosh]

Post by R2-D2
The files are identical, their timestamps are identical to the nanosecond.
Any clue?

chmod permissions?

[R2-D2]

Post by John Forkosh

Post by R2-D2
The files are identical, their timestamps are identical to the nanosecond.
Any clue?

chmod permissions?

nope :-(

-rw-r--r-- on both sides.

username, uid, gid are also identical.

Groan...

[Lew Pitcher]

Post by R2-D2
Local machine just upgraded from 14.2 to 15.0. Rsync package version 3.2.3-x86_64-4.
Remote machine still on 14.2,
rsync package version 3.1.3-x86_64-1_slack14.2.
I have a directory on the remote machine that has always been backed up locally
with rsync. After switching to 15 every single file "is newer" on the local
machine, where it has always been "is uptodate".
The files are identical, their timestamps are identical to the nanosecond. Any
clue? Idiosyncrasies between different rsync versions?
Thanks.

Apparently, idiosyncratic behavior that is corrected in the next upstream release of rsync.

See https://download.samba.org/pub/rsync/NEWS

"Fixed --update -vv to output "is uptodate" instead of "is newer" messages for files that are being skipped due to an identical modify time. (This was a new output quirk in 3.2.3.)"

[R2-D2]

Post by Lew Pitcher

Post by R2-D2
Local machine just upgraded from 14.2 to 15.0. Rsync package version 3.2.3-x86_64-4.
Remote machine still on 14.2, rsync package version
3.1.3-x86_64-1_slack14.2.
I have a directory on the remote machine that has always been backed up
locally with rsync. After switching to 15 every single file "is newer" on
the local machine, where it has always been "is uptodate".
The files are identical, their timestamps are identical to the nanosecond.
Any clue? Idiosyncrasies between different rsync versions?
Thanks.

Apparently, idiosyncratic behavior that is corrected in the next upstream release of rsync.
See https://download.samba.org/pub/rsync/NEWS
"Fixed --update -vv to output "is uptodate" instead of "is newer" messages
for files that are being skipped due to an identical modify time. (This was a
new output quirk in 3.2.3.)"

Excellent news, thanks. I'll sit tight, looking forward to see
http://ftp.slackware.com/pub/slackware/slackware-15.0/slackware/n/rsync-3.2.3-i586-4.txz
replaced by 3.2.4.

[Henrik Carlqvist]

Post by R2-D2
looking forward to see
http://ftp.slackware.com/pub/slackware/slackware-15.0/slackware/n/

rsync-3.2.3-i586-4.txz

Post by R2-D2
replaced by 3.2.4.

That is probably not going to happen. In the best case you will one day
find an updated rsync in http://ftp.slackware.com/pub/slackware/
slackware-15.0/slackware/patches , but that is probably only going to
happen if some kind of security hole is found in rsync.

If you want the latest greatest version of all applications with its
advantages and disadvantages you should run Slackware current instead of
the stable Slackware 15.

If you are lucky you will be able to use an updated package from
Slackware current in Slackware 15.0.

regards Henrik

[Lew Pitcher]

Post by R2-D2

Post by R2-D2
looking forward to see
http://ftp.slackware.com/pub/slackware/slackware-15.0/slackware/n/

rsync-3.2.3-i586-4.txz

Post by R2-D2
replaced by 3.2.4.

That is probably not going to happen. In the best case you will one day
find an updated rsync in http://ftp.slackware.com/pub/slackware/
slackware-15.0/slackware/patches , but that is probably only going to
happen if some kind of security hole is found in rsync.

I concur. Pat V. plays a conservative game, only upgrading packages to
cover specific needs (like changing timezone info) or specific threats
(like security exposures). It seems unlikely that Slackware would issue
a new rsync package simply to address a minor reporting issue.

Post by R2-D2
If you want the latest greatest version of all applications with its
advantages and disadvantages you should run Slackware current instead of
the stable Slackware 15.
If you are lucky you will be able to use an updated package from
Slackware current in Slackware 15.0.

Here's where you and I differ; with Slackware 15.0 /just/ released, it
seems, to me, to be a little, shall we say, imprudent to run Slackware
unstable, /just/ on the hopes of getting an update to /one/ package.

If I were in the OP's position, I'd simply download the rsync 3.2.4 source,
when it finally gets out of beta, and compile it myself. I'd use that
locally-installed rsync until Slackware releases it's own version.

For that matter, I'd build a local Slackware package (pkgtools aren't all
that hard to use), so that I can revert the change when Slackware releases
the official package.

Just my 2 cents worth here :-)

[Rich]

Post by Lew Pitcher
If I were in the OP's position, I'd simply download the rsync 3.2.4
source, when it finally gets out of beta, and compile it myself. I'd
use that locally-installed rsync until Slackware releases it's own
version.

Yes, this would be the proper way to proceed.

Post by Lew Pitcher
For that matter, I'd build a local Slackware package (pkgtools aren't
all that hard to use), so that I can revert the change when Slackware
releases the official package.

The OP could use the rsync slackbuild from 15.0 to build the newer
rsync and package it up as a slackware package. Then, should a
security patch be issued by Pat at some point in the future, all the OP
needs to do is download the newer release, and do 'upgradepkg'.

[R2-D2]

Post by R2-D2

Post by Lew Pitcher

Post by R2-D2
Local machine just upgraded from 14.2 to 15.0. Rsync package version 3.2.3-x86_64-4.
Remote machine still on 14.2, rsync package version
3.1.3-x86_64-1_slack14.2.
I have a directory on the remote machine that has always been backed up
locally with rsync. After switching to 15 every single file "is newer" on
the local machine, where it has always been "is uptodate".
The files are identical, their timestamps are identical to the nanosecond.
Any clue? Idiosyncrasies between different rsync versions?
Thanks.

Apparently, idiosyncratic behavior that is corrected in the next upstream
release of rsync.
See https://download.samba.org/pub/rsync/NEWS
"Fixed --update -vv to output "is uptodate" instead of "is newer" messages
for files that are being skipped due to an identical modify time. (This was a
new output quirk in 3.2.3.)"

Excellent news, thanks. I'll sit tight, looking forward to see
http://ftp.slackware.com/pub/slackware/slackware-15.0/slackware/n/rsync-3.2.3-i586-4.txz
replaced by 3.2.4.

3.2.4 came out a month ago:
https://download.samba.org/pub/rsync/NEWS#3.2.4
but it hasn't made its way into the slackware-15.0 repo yet. I guess it's time
to learn to build my own packages. :-)

[Chris Elvidge]

Post by R2-D2

Post by R2-D2

Post by Lew Pitcher

Post by R2-D2
Local machine just upgraded from 14.2 to 15.0. Rsync package version 3.2.3-x86_64-4.
Remote machine still on 14.2, rsync package version
3.1.3-x86_64-1_slack14.2.
I have a directory on the remote machine that has always been backed up
locally with rsync. After switching to 15 every single file "is newer" on
the local machine, where it has always been "is uptodate".
The files are identical, their timestamps are identical to the nanosecond.
Any clue? Idiosyncrasies between different rsync versions?
Thanks.

Apparently, idiosyncratic behavior that is corrected in the next upstream
release of rsync.
See https://download.samba.org/pub/rsync/NEWS
"Fixed --update -vv to output "is uptodate" instead of "is newer" messages
for files that are being skipped due to an identical modify time. (This was a
new output quirk in 3.2.3.)"

Excellent news, thanks. I'll sit tight, looking forward to see
http://ftp.slackware.com/pub/slackware/slackware-15.0/slackware/n/rsync-3.2.3-i586-4.txz
replaced by 3.2.4.

https://download.samba.org/pub/rsync/NEWS#3.2.4
but it hasn't made its way into the slackware-15.0 repo yet. I guess
it's time to learn to build my own packages. :-)

Have you looked in Slackware-current?
e.g.
https://mirror.bytemark.co.uk/slackware/slackware64-current/slackware64/n/

[R2-D2]

Post by Chris Elvidge

Post by R2-D2

Post by R2-D2

Post by Lew Pitcher

Post by R2-D2
Local machine just upgraded from 14.2 to 15.0. Rsync package version
3.2.3-x86_64-4.
Remote machine still on 14.2, rsync package version
3.1.3-x86_64-1_slack14.2.
I have a directory on the remote machine that has always been backed up
locally with rsync. After switching to 15 every single file "is newer" on
the local machine, where it has always been "is uptodate".
The files are identical, their timestamps are identical to the nanosecond.
Any clue? Idiosyncrasies between different rsync versions?
Thanks.

Apparently, idiosyncratic behavior that is corrected in the next upstream
release of rsync.
See https://download.samba.org/pub/rsync/NEWS
"Fixed --update -vv to output "is uptodate" instead of "is newer" messages
for files that are being skipped due to an identical modify time. (This was a
new output quirk in 3.2.3.)"

Excellent news, thanks. I'll sit tight, looking forward to see
http://ftp.slackware.com/pub/slackware/slackware-15.0/slackware/n/rsync-3.2.3-i586-4.txz
replaced by 3.2.4.

https://download.samba.org/pub/rsync/NEWS#3.2.4
but it hasn't made its way into the slackware-15.0 repo yet. I guess it's time
to learn to build my own packages. :-)

Have you looked in Slackware-current?
e.g. https://mirror.bytemark.co.uk/slackware/slackware64-current/slackware64/n/

Wow, you are right!
http://ftp.slackware.com/pub/slackware/slackware64-current/slackware64/n/rsync-3.2.4-x86_64-1.txz
But I wonder, is it safe in general to install current packages in a stable
version? Current has a different kernel version (5.17.8) from 15.0 (5.15.38).
Could that be a problem?

[Chris Elvidge]

Post by R2-D2

Post by Chris Elvidge

Post by R2-D2

Post by R2-D2

Post by Lew Pitcher

Post by R2-D2
Local machine just upgraded from 14.2 to 15.0. Rsync package version
3.2.3-x86_64-4.
Remote machine still on 14.2, rsync package version
3.1.3-x86_64-1_slack14.2.
I have a directory on the remote machine that has always been backed up
locally with rsync. After switching to 15 every single file "is newer" on
the local machine, where it has always been "is uptodate".
The files are identical, their timestamps are identical to the nanosecond.
Any clue? Idiosyncrasies between different rsync versions?
Thanks.

Apparently, idiosyncratic behavior that is corrected in the next upstream
release of rsync.
See https://download.samba.org/pub/rsync/NEWS
"Fixed --update -vv to output "is uptodate" instead of "is newer" messages
for files that are being skipped due to an identical modify time. (This was a
new output quirk in 3.2.3.)"

Excellent news, thanks. I'll sit tight, looking forward to see
http://ftp.slackware.com/pub/slackware/slackware-15.0/slackware/n/rsync-3.2.3-i586-4.txz
replaced by 3.2.4.

https://download.samba.org/pub/rsync/NEWS#3.2.4
but it hasn't made its way into the slackware-15.0 repo yet. I guess
it's time to learn to build my own packages. :-)

Have you looked in Slackware-current?
e.g.
https://mirror.bytemark.co.uk/slackware/slackware64-current/slackware64/n/

Wow, you are right!
http://ftp.slackware.com/pub/slackware/slackware64-current/slackware64/n/rsync-3.2.4-x86_64-1.txz
But I wonder, is it safe in general to install current packages in a
stable version? Current has a different kernel version (5.17.8) from
15.0 (5.15.38). Could that be a problem?

Why would the kernel version make a difference?
Void (for e.g.) has rsync 3.2.4 and kernel 5.16.20

[R2-D2]

Post by Chris Elvidge

Post by R2-D2

Post by Chris Elvidge

Post by R2-D2

Post by R2-D2

Post by Lew Pitcher

Post by R2-D2
Local machine just upgraded from 14.2 to 15.0. Rsync package version
3.2.3-x86_64-4.
Remote machine still on 14.2, rsync package version
3.1.3-x86_64-1_slack14.2.
I have a directory on the remote machine that has always been backed up
locally with rsync. After switching to 15 every single file "is newer" on
the local machine, where it has always been "is uptodate".
The files are identical, their timestamps are identical to the nanosecond.
Any clue? Idiosyncrasies between different rsync versions?
Thanks.

Apparently, idiosyncratic behavior that is corrected in the next upstream
release of rsync.
See https://download.samba.org/pub/rsync/NEWS
"Fixed --update -vv to output "is uptodate" instead of "is newer" messages
for files that are being skipped due to an identical modify time. (This was a
new output quirk in 3.2.3.)"

Excellent news, thanks. I'll sit tight, looking forward to see
http://ftp.slackware.com/pub/slackware/slackware-15.0/slackware/n/rsync-3.2.3-i586-4.txz
replaced by 3.2.4.

https://download.samba.org/pub/rsync/NEWS#3.2.4
but it hasn't made its way into the slackware-15.0 repo yet. I guess it's
time to learn to build my own packages. :-)

Have you looked in Slackware-current?
e.g. https://mirror.bytemark.co.uk/slackware/slackware64-current/slackware64/n/

Wow, you are right!
http://ftp.slackware.com/pub/slackware/slackware64-current/slackware64/n/rsync-3.2.4-x86_64-1.txz
But I wonder, is it safe in general to install current packages in a stable
version? Current has a different kernel version (5.17.8) from 15.0 (5.15.38).
Could that be a problem?

Why would the kernel version make a difference?
Void (for e.g.) has rsync 3.2.4 and kernel 5.16.20

Ok, the kernel may be fine, but this is what I get when running rsync-3.2.4 from
current on a 15.0:

rsync: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by rsync)

I'd rather not mess up other things trying to install glibc from current to 15.0.

[Henrik Carlqvist]

Post by R2-D2
But I wonder, is it safe in general to install current packages in a
stable version?

I would say that in general it would be a better idea to use the
Slackbuild script together with sources to try to build the package from
current on your stable installation. As you say, kernel and library
versions might differ. Those differences might cause the new version not
to build, but if it builds it is good hope that the built binary will
work. If it doesn't build, I would start by comparing the Slackbuild
scripts between stable and current, maybe some new feature has been
enabled which needs to be disabled on stable?

regards Henrik

[R2-D2]

Post by Henrik Carlqvist

Post by R2-D2
But I wonder, is it safe in general to install current packages in a
stable version?

I would say that in general it would be a better idea to use the
Slackbuild script together with sources...

Ok, so this is what I've done:

1) downloaded the folder
http://ftp.slackware.com/pub/slackware/slackware-current/source/n/rsync/;
2) made executable, and ran as root, ./rsync.SlackBuild;
3) upgradepkg /tmp/rsync-3.2.4-x86_64-1.txz;
4) happily ran rsync, the "is newer" bug is gone.

Just wondering. Why did Pat turn
https://download.samba.org/pub/rsync/src/rsync-3.2.4.tar.gz *(1.1M)* into
http://ftp.slackware.com/pub/slackware/slackware-current/source/n/rsync/rsync-3.2.4.tar.lz
*(728K)*?
Just to save disk space? The content is identical, I checked the hashes of every
single file.

Thanks everyone.

[Rich]

Post by R2-D2
Just wondering. Why did Pat turn
https://download.samba.org/pub/rsync/src/rsync-3.2.4.tar.gz *(1.1M)* into
http://ftp.slackware.com/pub/slackware/slackware-current/source/n/rsync/rsync-3.2.4.tar.lz
*(728K)*?
Just to save disk space? The content is identical, I checked the hashes of every
single file.

That looks to be the reason. Your numbers above show the .lz file as a
bit over 25% smaller than the .gz original. Multiply an approximate
25% shrink across *all* source packages and you have quite a
substantial disk space savings.

And when trying to package into DVD disk sized chunks, disk space
savings can mean the difference between fitting into X vs X+1 DVD
disks.

[Henrik Carlqvist]

Post by Rich
And when trying to package into DVD disk sized chunks, disk space
savings can mean the difference between fitting into X vs X+1 DVD disks.

Yes, locking at the installation isos for Slackware 14.2 you can see that
the source directory has been omitted completely. This is probably
because the source directory contains more than 6 GB of data and in
itself would not fit on a single layer DVD (4.5 GB). Together with the
rest of the installation files it would not even fit on a dual layer DVD
(8.5 GB). To have the source directory in an ISO together with the rest
of the Slackware installation files would require a bluray disc to burn.

regards Henrik

[Chris Elvidge]

Post by R2-D2

Post by Henrik Carlqvist

Post by R2-D2
But I wonder, is it safe in general to install current packages in a
stable version?

I would say that in general it would be a better idea to use the
Slackbuild script together with sources...

1) downloaded the folder
http://ftp.slackware.com/pub/slackware/slackware-current/source/n/rsync/;
2) made executable, and ran as root, ./rsync.SlackBuild;
3) upgradepkg /tmp/rsync-3.2.4-x86_64-1.txz;
4) happily ran rsync, the "is newer" bug is gone.
Just wondering. Why did Pat turn
https://download.samba.org/pub/rsync/src/rsync-3.2.4.tar.gz *(1.1M)* into
http://ftp.slackware.com/pub/slackware/slackware-current/source/n/rsync/rsync-3.2.4.tar.lz
*(728K)*?
Just to save disk space? The content is identical, I checked the hashes
of every single file.
Thanks everyone.

Advantages of .lz
https://fileinfo.com/extension/lz