Hello to everyone.
I'm trying to copy all the system files of Rocky Linux 9 from within
Ubuntu-2404-KDE6-Wayland vm to outside the vm,directly on the UFS fs of
FreeBSD 14.2 using this command :
rsync -avxHAXP * /FreeBSD/compat/linux
but I get a lot of errors :
/include/c
t use -a and instead use the remaining
> combination of options explicitly, or use --no-p.
>
> See the man page, specifically the sections for --perms and -a.
When I stepped this through the debugger I found that this was not the case.
The flaw is on this line:
https://github.com/Rs
On Tue, Apr 08, 2025 at 12:54:24PM +0100, Graham Leggett via rsync wrote:
> I misunderstood the --chmod option, thinking that it specified the
> permissions at the destination. What actually happens is that it
> overrides the source permissions, and has a side effect of the
>
On 21 Apr 2025, at 06:37, TheNew HEROBRINE via rsync
wrote:
> For your situation I think you should use both --fake-super and -M--super
> because reading the manual it says:
> "For a local copy, this option affects both the source and the destination.
> If you wish a local co
f you wish a local copy to enable this
option just for the source files, combine --fake-super with -M--super"
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting,
On 08 Apr 2025, at 12:54, Graham Leggett via rsync
wrote:
> Another thing I've found is that my backups have lost their permissions.
>
> I misunderstood the --chmod option, thinking that it specified the
> permissions at the destination. What actually happens is that it
reverse and restore.
Google is hallucinating some nonsense, so that's a dead end.
Can anyone confirm what modification needs to be made to this command line to
recover symlinks, permissions and owners:
rsync -av --numeric-ids /mnt/backup/root/ /mnt/root/
[--what-extra-params-go-here]
Note
On 08 Apr 2025, at 10:28, Graham Leggett via rsync
wrote:
> Unfortunately all combinations of --fake-super that I have used so far have
> had the effect of backing up the backup, not restoring the backup.
Looking in the source code, it looks like the difference between rsync
perfor
On 08 Apr 2025, at 10:04, Paul Slootman via rsync wrote:
>> I have a backup that was created with --fake-super that I need to restore to
>> a fresh partition on the same machine as the backup (source and destination
>> on the same machine).
>>
>> The docs descri
https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
On Tue 08 Apr 2025, Graham Leggett via rsync wrote:
>
> I have a backup that was created with --fake-super that I need to restore to
> a fresh partition on the same machine as the backup (source and destination
> on the same machine).
>
> The docs describe how --fake-super i
On March 3, 2025 10:28 PM, Kevin Korb wrote:
>Works for me...
>$ ./configure --disable-iconv --disable-locale --disable-openssl
>--disable-xxhash --
>disable-zstd --disable-lz4 && make $ ldd rsync
> linux-vdso.so.1 (0x7ffd39873000)
> libc.so.6 =>
Works for me...
$ ./configure --disable-iconv --disable-locale --disable-openssl
--disable-xxhash --disable-zstd --disable-lz4 && make
$ ldd rsync
linux-vdso.so.1 (0x7ffd39873000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f77c8f8b000)
/lib64/l
On March 3, 2025 9:14 PM Marc Aurèle La France wrote:
>On Mon, 2025-Mar-03, Randall S. Becker via rsync wrote:
>
>> I am trying to build a 64-bit version of rsync. My issue is that I do
>> not have a 64-bit libiconv.so or libiconv.a available. The platform I
>> am on onl
On Mon, 2025-Mar-03, Randall S. Becker via rsync wrote:
I am trying to build a 64-bit version of rsync. My issue is that I do not
have a 64-bit libiconv.so
or libiconv.a available. The platform I am on only has 32-bit builds. The
--disable-iconv option
in configure is not actually disabling
Hi Rsync Team,
I am trying to build a 64-bit version of rsync. My issue is that I do not
have a 64-bit libiconv.so
or libiconv.a available. The platform I am on only has 32-bit builds. The
--disable-iconv option
in configure is not actually disabling iconv. Is there a different option to
disable
has a maximum path length of 1024 (like in [2]), and I cannot change
rsync on the remote end.
My question is what I can do on the local end to not abort the rsync
run on long paths. I would like rsync to skip the file and move on.
Maybe compile the local rsync with MAXPATHLEN=1024?
Thanks,
my setup":
Even though I may write workaround-code to rsync to do what I want -
someone else may not.
Therefore, if certain basic functionalities are not available upstream,
I doubt they will be picked up "as an option" by others.
At least that's the case in my domain (GL
ps://github.com/RsyncProject/rsync/pull/719
>
> It allows you to truncate your local files after transfer. Outside of rsync,
> you must then truncate the file to zero size, then set the time stamp back to
> the original time. On the next run, the file will not be retransmitted as it
Actually... I have made an extremely small and simple patch implementing an
option --time-only, and I have made a pull request for it:
https://github.com/RsyncProject/rsync/pull/719
It allows you to truncate your local files after transfer. Outside of rsync,
you must then truncate the file to
Hello everyone :)
I'd like to follow up on this thread of mine, if that's okay?
Is there anything I could do to get the feature functionality of "using
rsync to create a thin (attributes-only) copy" upstream on the long term?
Could I talk to a developer, for hire?
I
Hi all,
for an rsync-based incremental mechanism we use quite some pre- and
post-processing through pre-xfer and post-xfer. However it has turned
out, that the pre- and post-processing scripts must be able to differ
between uploads and downloads, as we require different processing steps
in
* "rsync.project via rsync"
:
Wrote on Wed, 15 Jan 2025 09:34:10 +1100:
> sorry about the prefix changes in rsync-patches. We're going to be dropping
> the whole rsync-patches system soon anyway, as it really isn't working
> well. It was supposed to be a staging ar
> I don't believe the transferring part of rsync will jump around.
How about the deleting part?
> It will transfer files it deems need it in the order it finds them
> which will be 1 dir at a time. Though when it enters a child dir that
> doesn't mean it is done with t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I don't believe the transferring part of rsync will jump around. It
will transfer files it deems need it in the order it finds them which
will be 1 dir at a time. Though when it enters a child dir that doesn't
mean it is done with the
Thanks for your message again. I appreciate your answers.
I don't mind about the order of the files, and neither really about the
order of the directories: I'm interested about whether rsync might
transfer some files into a directory, then transfer some files into
another which is outs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There is no guarantee that rsync will do anything in any order since it
is going by the filesystem without any sorting. With --delete-during
the directory indexing and therefore the deletions are running in
parallel with file transfers. This means
Thanks Kevin,
but I don't understand your message, or at least how it answers my "real
question" (last paragraph)... and by the way --delete defaults to
--delete-during for current versions of rsync as far as I know...
> rsync doesn't really give much control over the or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
rsync doesn't really give much control over the order it does things in.
If you want to control when the deletions happen there is only
- --delete-before or --delete-during but both are slower than the default
- --delete.
On Thu, 16 Jan 2025, B
On Thu, 2025-Jan-16, BP via rsync wrote:
I always run rsync as follows: "sudo rsync -PaSHAXvi --del DIR1/
DIR2". I would think that whenever I see in the output of this rsync
command a few lines of the form A/B/... and then further down in the
output again a few lines of the form A/B
Hello,
I always run rsync as follows: "sudo rsync -PaSHAXvi --del DIR1/
DIR2". I would think that whenever I see in the output of this rsync
command a few lines of the form A/B/... and then further down in the
output again a few lines of the form A/B/... (dots are dirs or files),
then
hat sort of worked, but didn't handle the
82-bit registers of IA-64.
However, I have a physical IA-64 server box that runs Red Hat
Enterprise Linux Server release 5.11 (Tikanga). I successfully built
rsync-3.4.0 on it yesterday like this:
$ export PATH=/usr/bin:/bin:/usr/sbin:/sbin
Due to some regressions in 3.4.0 we have released 3.4.1.
See https://download.samba.org/pub/rsync/NEWS#3.4.1 for details of the
changes
Our apologies for not catching these issues before 3.4.0
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change
As you seem to be around now, could we do a call to try and get this fixed?
Are you on the rsync discord server?
https://discord.gg/zHzPNc6R
if you can't do discord, then zoom?
On Thu, 16 Jan 2025 at 06:18, wrote:
> Also, the patch I previously sent works correctly on x86, but not ia64
Hutchison ; rsync@lists.samba.org
Subject: Re: new release 3.4.0 - critical security release
Is there a way I can get access to a machine 3.4.0 is failing to build on?
Maybe a VM under VirtualBox? Or some cloud service?
I don't have an ia64
On Thu, 16 Jan 2025 at 01:20, mailto:
Also, the patch I previously sent works correctly on x86, but not ia64. This
problem is isolated to popt/findme
From: rsync.project
Sent: January 15, 2025 2:11 PM
To: rsbec...@nexbridge.com
Cc: Perry Hutchison ; rsync@lists.samba.org
Subject: Re: new release 3.4.0 - critical security
Is there a way I can get access to a machine 3.4.0 is failing to build on?
Maybe a VM under VirtualBox? Or some cloud service?
I don't have an ia64
On Thu, 16 Jan 2025 at 01:20, wrote:
> On January 14, 2025 11:20 PM, Perry Hutchison wrote:
> >"Randall S. Becker via rsync&qu
On January 14, 2025 11:20 PM, Perry Hutchison wrote:
>"Randall S. Becker via rsync" wrote:
>
>> FYI: I think this is just missing #include "rsync.h" in popt/findme.c
>
>Structurally, this seems very odd. I thought popt was a generic argument
handler,
>whi
Building for NonStop x86 and ia64. What is VINCE and where do notifications go
for that?
From: rsync.project
Sent: January 15, 2025 2:02 AM
To: rsbec...@nexbridge.com
Cc: rsync@lists.samba.org
Subject: Re: new release 3.4.0 - critical security release
I'd also note that the patche
ers, Tridge
>
> On Wed, 15 Jan 2025 at 14:35, wrote:
>
>> Another issue here in findme.c. strlcpy() is a BSD-only method and
>> definitely not portable.
>>
>> Please consider other platforms when creating patches. I can provide a
>> patch to this
>>
>
Another issue here in findme.c. strlcpy() is a BSD-only method and
> definitely not portable.
>
> Please consider other platforms when creating patches. I can provide a
> patch to this
>
> patch also.
>
>
>
> Thanks,
>
> Randall
>
>
>
> *From:* rsy
"Randall S. Becker via rsync" wrote:
> FYI: I think this is just missing #include "rsync.h" in popt/findme.c
Structurally, this seems very odd. I thought popt was a generic
argument handler, which should not need to #include details of the
application that is using it
FYI: I think this is just missing #include “rsync.h” in popt/findme.c
From: rsbec...@nexbridge.com
Sent: January 14, 2025 10:35 PM
To: rsbec...@nexbridge.com; 'rsync.project'
Cc: rsync@lists.samba.org
Subject: RE: new release 3.4.0 - critical security release
Another iss
Another issue here in findme.c. strlcpy() is a BSD-only method and definitely
not portable.
Please consider other platforms when creating patches. I can provide a patch to
this
patch also.
Thanks,
Randall
From: rsync On Behalf Of Randall S. Becker via
rsync
Sent: January 14, 2025 6
I don't have a Mac to test on. If you have a Mac maybe you could test and
open a PR against rsync for the change?
On Wed, 15 Jan 2025 at 10:12, Ryan Carsten Schmidt
wrote:
> On Jan 14, 2025, at 16:34, rsync.project wrote:
>
>
> sorry about the prefix changes in rsync-patches.
ully ask that it be included ASAP.
Thanks,
Randall
From: rsync On Behalf Of Randall S. Becker via
rsync
Sent: January 14, 2025 6:09 PM
To: 'rsync.project'
Cc: rsync@lists.samba.org
Subject: RE: new release 3.4.0 - critical security release
This happens on NonStop x86 and ia64. I h
On Jan 14, 2025, at 16:34, rsync.project wrote:sorry about the prefix changes in rsync-patches.No problem; those changes were easy to remove from the fileflags patch. We're going to be dropping the whole rsync-patches system soon anyway, as it really isn't working well. It was suppos
This happens on NonStop x86 and ia64. I have been building/packaging Rsync for
years – almost a decade in fact. I think this happened once before this year,
in fact.
It is equivalent to the more portable malloc/free, which I would prefer to have
in this series even if it has to be wrapped
sorry about the prefix changes in rsync-patches. We're going to be dropping
the whole rsync-patches system soon anyway, as it really isn't working
well. It was supposed to be a staging area where users would test the
patches before being considered for the main release, but we have
The patches within the rsync-patches-3.4.0.tar.gz archive seem to contain new
unnecessary hunks that change the prefix from /usr to /usr/local. This was not
the case in 3.3.0.
I use the fileflags.diff patch in the MacPorts build of rsync, and with the
3.4.0 version of this patch, it does not
the alloca comes from the new popt release. What system are you having an
issue with?
On Wed, 15 Jan 2025 at 07:16, wrote:
> A new dependency was added since 3.3, alloca(), which is not portable. Is
> there a way around this?
>
> Thanks,
>
> Randall
>
>
>
>
A new dependency was added since 3.3, alloca(), which is not portable. Is there
a way around this?
Thanks,
Randall
From: rsync On Behalf Of rsync.project via rsync
Sent: January 14, 2025 2:49 PM
To: rsync-annou...@lists.samba.org
Cc: rsync@lists.samba.org
Subject: new release 3.4.0
"rsync.project via rsync" writes:
> We have just released version 3.4.0 of rsync. This release fixes 6 security
> vulnerabilities found by two
> groups of security researchers.
>
> You can find the new release links here:
>
> - https://rsync.samba.org/
> - ht
We have just released version 3.4.0 of rsync. This release fixes 6 security
vulnerabilities found by two groups of security researchers.
You can find the new release links here:
- https://rsync.samba.org/
- https://download.samba.org/pub/rsync/src/
For details on the vulnerabilities please
Thanks for the advice. Unfortunately I tried:
--link-dest=/snapshots/rsync_test/last
and it still does not find it.
On Sun, Jan 12, 2025 at 8:37 AM Paul Slootman via rsync
wrote:
>
> On Sat 11 Jan 2025, Anthony LaTorre via rsync wrote:
>
> > Thanks for your quick response. The r
On Sat 11 Jan 2025, Anthony LaTorre via rsync wrote:
> Thanks for your quick response. The rsyncd.conf file looks like:
>
> charset = utf-8
> [user]
> path = /c/user
> comment = ""
> use chroot = true
Note the chroot... So "/" equals /c/user
&g
On 12.01.25 03:52, Anthony LaTorre via rsync wrote:
$ rsync -aPh --link-dest=/user/snapshots/rsync_test/last
/home/user/rsync_test
rsync://admin@readynas.internal/snapshots/user/Jan_11_2025
Password:
sending incremental file list
--link-dest arg does not exist: /user/snapshots/rsync_test/last
IX path is:
/c/user/snapshots/rsync_test/last
I've tried:
--link-dest=snapshots/rsync_test/last
--link-dest=./snapshots/rsync_test/last
--link-dest=../last
but none seem to work.
Thanks,
Tony
On Sat, Jan 11, 2025 at 9:02 PM Kevin Korb via rsync
wrote:
>
> rsyncd doesn't t
rsyncd doesn't take unix paths. You must adapt your --link-dest to
contend with however the rsycd module is defined in rsyncd.conf.
On 1/11/25 9:52 PM, Anthony LaTorre via rsync wrote:
Hi all,
I'm trying to figure out why a script works when using SSH but not
when using the rsyn
Hi all,
I'm trying to figure out why a script works when using SSH but not
when using the rsync protocol. When I run the following command:
rsync -aPh --link-dest=/user/snapshots/rsync_test/last
/home/user/rsync_test
root@readynas.internal:/user/snapshots/rsync_test/Jan_11_2025
it
On 24.12.24 09:53, Mario Marietto via rsync wrote:
There are times when a large file is copied up to 99% and then deleted after
having received the error. Other times when the error occurs earlier and only a
part of it is copied. Does it make sense to calculate the checksum if in both
cases
s: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
>
> https://stackoverflow.com/questions/478722/what-is-the-best-way-to-calculate-a-checksum-for-a-file-that-is-on-my-machine
>
> On Mon, Dec 23, 2024 at 11:02:21PM +0100, Mario Marietto via rsync wrote:
> > -> Are you running windows on the same hardware as Linux/BSD ? Is it
If you have different systems for windows vslinux, it's possible there is
> a HW issue with one of them.
>
>
> Tom
>
>
> On 24 December 2024 7:44:16 am GMT+12:00, Mario Marietto via rsync <
> rsync@lists.samba.org> wrote:
>
>> What would you think if I t
Mario,
Are you running windows on the same hardware as Linux/BSD ? Is it a dual-boot
system?
If you have different systems for windows vslinux, it's possible there is a HW
issue with one of them.
Tom
On 24 December 2024 7:44:16 am GMT+12:00, Mario Marietto via rsync
wrote:
> Wh
-> Did you re-read the data and compare checksums ?
Don't know how to do this.
-> 2nd thought: What file systems do you use, and is there a peculiar size
of the file, hitting a limit?
Do I read this correct, rsync throws the error at
320,072,933,376, then continues to
640,302,152,539
On 23.12.24 20:44, Mario Marietto via rsync wrote:
What would you think if I told you that using Windows I no longer had that
problem ?
Would you still think that there are hardware problems ?
And if so, why would they only manifest themselves using Linux and FreeBSD and
not using Windows
ng Windows 11 because I want
> to
> > > exclude some variables from the equation.
> > >
> > > On Mon, Dec 23, 2024 at 7:49 PM Robin Lee Powell <
> > > rlpow...@digitalkingdom.org> wrote:
> > >
> > >> Almost certainly your drive is going ba
On Linux I'd tell you to
>> check dmesg for drive errors, I don't know what the FreeBSD
>> equivalent is. But I strongly recommend that you treat that drive
>> as "going to fail any second".
>>
>> On Mon, Dec 23, 2024 at 12:56:09PM +0100, Mario Mari
ivalent is. But I strongly recommend that you treat that drive
> as "going to fail any second".
>
> On Mon, Dec 23, 2024 at 12:56:09PM +0100, Mario Marietto via rsync wrote:
> > Using the parameters below the file hasn't been removed at 100% even if I
> > got the
Using the parameters below the file hasn't been removed at 100% even if I
got the same error :
root@Z390-AORUS-PRO-DEST:/mnt/zroot-133/A_FILES/Backup/FreeBSD# rsync
--inplace --append --partial Free
BSD-141-UFS-sdc-DarkMatter.img /mnt/sdj1/OS/Backup/BSD/FreeBSD
rsync: [sender] read e
Happened again :
root@Z390-AORUS-PRO-DEST:/mnt/zroot-133/A_FILES/Backup/FreeBSD# sudo rsync
-azvvP FreeBSD-141-UFS-sdc-DarkMatter.img /mnt/sdj1/OS/Backup/BSD/FreeBSD
sending incremental file list
delta-transmission disabled for local transfer or --whole-file
FreeBSD-141-UFS-sdc-DarkMatter.img
>As it's just a single file you're trying to copy, why not use cp?
>Although I expect that cp will also throw an IO error at some point.
Yes,I tried cp and I got the same error,that usually happens before
rsync,that is able to complete the transfer until 99%.
I've detached a
On Mon 23 Dec 2024, Mario Marietto via rsync wrote:
>
> Everytime I try to copy a file from one USB disk to another one (does not
> matter which one),I get this kind of error :
>
>
> mario@Z390-AORUS-PRO-DEST:/mnt/zroot-133/A_FILES/Backup/FreeBSD# rsync
> -avxHAX
Hello.
Everytime I try to copy a file from one USB disk to another one (does not
matter which one),I get this kind of error :
mario@Z390-AORUS-PRO-DEST:/mnt/zroot-133/A_FILES/Backup/FreeBSD# rsync
-avxHAXP FreeBSD-141-UFS-sdc-DarkMatter.img
/mnt/sdj1/OS/Backup/BSD/FreeBSD --ignore-existing
cribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Hi everyone :)
I'm professionally and seriously working with extended filesystem
attributes (xattrs) for search/retrieval of data.
I am making a "thincopy" of large data trees, like this:
`$ cp --attributes-only --preserve=all $(SOURCE) $(TARGET)`
Is there a way to do this
icial source" of this article?
That article must be mirrored and/or archived in dozens, if not
hundreds, of other places. Maybe someone (ahem) sane can find a
better target for the link.
I guess it'd be a good idea to somehow resolve this, as many systems are
switching to force-https?
.
On 12/9/24 17:11, Peter B. via rsync wrote:
Hi everyone :)
On the [official website regarding rsync mailing lists](https://
rsync.samba.org/lists.html), the text contains a link:
"but please [read this before posting]"
Which points to:
https://www.catb.org/~esr/faqs/smart-ques
"Peter B. via rsync" wrote:
> On the [official website regarding rsync mailing
> lists](https://rsync.samba.org/lists.html), the text contains a link:
>
> "but please [read this before posting]"
>
> Which points to:
> https://www.catb.org/~esr/faq
Hi everyone :)
On the [official website regarding rsync mailing
lists](https://rsync.samba.org/lists.html), the text contains a link:
"but please [read this before posting]"
Which points to:
https://www.catb.org/~esr/faqs/smart-questions.html
Which throws a "bad_domain_e
I found this helpful re /3:
https://serverfault.com/questions/373058/comparing-owners-and-permissions-of-content-of-two-folders
If there's any gotchas that jump out - jump on in.
M
On 08/12/2024 2:28 pm, Morgan Read wrote:
Hello List,
I've been running rsync for must be 20 years b
Hello List,
I've been running rsync for must be 20 years by now, but over that time
the holes in the Swiss cheese that passes for my brain seem to have
grown larger and been filled with budgie seed and sawdust.
I once used rsync as my regular backup solution but now settle for a
k/mac/
On Fri, Nov 15, 2024 at 04:08:27PM +, Maxim Usatov via rsync wrote:
Dear All,
Having weird rsync issues after upgrading FreeBSD from 13.2 to 14.1 and
rsync along with it. I cannot find any solution. Setup: doing rsync backup
from the root ZFS to an SSD mounted to /media/da0p1. The rsy
On Sat, Nov 16, 2024 at 08:26:47AM GMT, Maxim Usatov via rsync wrote:
> Tried without nice, xattrs, acls and hard-links - same error.
Hmm okay, a real bug then :-) It likely has to do with the way cron
assumes the identity of the crontab owner. I would ask on the
freebsd-questions list. It
Hi Ian,
Tried without nice, xattrs, acls and hard-links - same error.
Regards,
Maxim Usatov
On 11/15/24 17:42, Ian Z via rsync wrote:
On Fri, Nov 15, 2024 at 04:08:27PM GMT, Maxim Usatov via rsync wrote:
I assume code 13 is related to permissions, but given rsync is
started as root, why
On Fri, Nov 15, 2024 at 04:08:27PM GMT, Maxim Usatov via rsync wrote:
> I assume code 13 is related to permissions, but given rsync is
> started as root, why would this happen? The same rsync commands
> worked on all previous versions of FreeBSD. It also fails with the
> same error
Dear All,
Having weird rsync issues after upgrading FreeBSD from 13.2 to 14.1 and
rsync along with it. I cannot find any solution. Setup: doing rsync
backup from the root ZFS to an SSD mounted to /media/da0p1. The rsync is
initiated as root using /etc/crontab. The log:
2024/11/15 08:30:01
alright, makes sense now thanks for the information
On Tue, Oct 29, 2024, at 21:32, Robin Lee Powell wrote:
> --exclude takes an argument, so "--exclude --exclude ." means
> "exclude files named --exclude, followed by . as a bare argument".
>
> So this is e
Hello,
Came across the following "sudo rsync -avh src/ dst --delete --exclude
--exclude ." this will apparently delete everything in the current dir except
for the dst dir, is this a bug?
rsync version 3.2.7 protocol version 31
Best regards
Mark--
Please use reply-all for most
https://bugzilla.samba.org/show_bug.cgi?id=6741
--- Comment #7 from Marc Aurèle La France ---
Created attachment 18484
--> https://bugzilla.samba.org/attachment.cgi?id=18484&action=edit
rsync stdout filter
Checkpoint III
--
You are receiving this mail because:
You are the QA Contact
Paul Slootman via rsync wrote:
> On Wed 16 Oct 2024, Chris Green via rsync wrote:
> >
> > I use it almost exclusively on Linux systems and it would be really
> > handy if I could set a number of options which would always be used
> > when I run rsync. These would be
On Wed 16 Oct 2024, Chris Green via rsync wrote:
>
> I use it almost exclusively on Linux systems and it would be really
> handy if I could set a number of options which would always be used
> when I run rsync. These would be in addition to -a which is useful
> but not quite
Hi,
This is mostly intended for the maintainers to read.
What's intended way to actually get patches merged into rsync?
I've tried:
- Mailing list posts
- GitHub PRs
--ignore-non-existing-directory
https://lists.samba.org/archive/rsync/2015-November/030455.html
https://github.com/Rs
On Wed 09 Oct 2024, McDowell, Blake via rsync wrote:
> Linux servers one running TrueNAS-13.0-U6 and the other running
> TrueNAS-13.0-U3.1.
>
> I connect to both on a Mac via smb over fiber.
>
> Using cp -a also updates the timestamp of the copied file to today and does
>
conservator/archivist, so I
may be missing something obvious.
-Blake
From: Kevin Korb
Date: Wednesday, October 9, 2024 at 15:01
To: McDowell, Blake , rsync@lists.samba.org
Subject: Re: Question About Rsync and Modification Times
External Email - Exercise Caution
That isn't how rsync s
That isn't how rsync should work with -a. Is something preventing it
from backdating the file? What is the filesystem? Can you try copying
your 2015 file with cp -a?
On 10/9/24 14:56, McDowell, Blake wrote:
Hi Kevin,
The -a flag in this instance is not back-dating the timestamp o
transfer. I have a source file the has
a modification date of 2015 and when I rsync it to day with -a the copied file
has a modification date of today.
Again, this only happens on files that I use rsync to copy for the first time
over to empty storage. If I drag and drop the timestamp stays the same as
You are using rsync -a which copies (preserves) the timestamp. Meaning
that rsync will copy the file then back-date it to the timestamp of the
source file. Most copying tools do not do this though cp's -a does it
too. Note that your itemized output says that the timestamp is
diff
Hello,
I have a question about how/why rsync updates modification times, which I
haven’t been able to find an answer to.
I have two locally connected storage devices running TrueNAS Core: one is new
and empty, while the other is filled with files.
When I run the following rsync command
1 - 100 of 2132 matches
Mail list logo
