https://bugzilla.samba.org/show_bug.cgi?id=12732
Bug ID: 12732
Summary: hard links can cause rsync to block or to silently
skip files
Product: rsync
Version: 3.1.2
Hardware: x64
OS: Linux
https://bugzilla.samba.org/show_bug.cgi?id=12732
--- Comment #1 from Hansjoerg Lipp ---
Am 05.04.2017 um 22:05 schrieb L A Walsh via rsync:
>I ran rsync 3.1.1 for over a year to help generate
> snapshots. I can't say if it copied all the files or not, as
> it was backing up
https://bugzilla.samba.org/show_bug.cgi?id=12741
Bug ID: 12741
Summary: stop rsync on "No space left on device"
Product: rsync
Version: 3.1.2
Hardware: x86
OS: Linux
Status: NEW
Severity: enhancement
https://bugzilla.samba.org/show_bug.cgi?id=12519
Ben RUBSON changed:
What|Removed |Added
Resolution|--- |LATER
https://bugzilla.samba.org/show_bug.cgi?id=12742
Bug ID: 12742
Summary: a proposal: fix bogus nanosecond mtimes on transfer
(patch included)
Product: rsync
Version: 3.1.1
Hardware: All
OS: All
https://bugzilla.samba.org/show_bug.cgi?id=12755
--- Comment #1 from Joseph Benden ---
If anyone wishes to test the compiled binary, it's available for download here:
https://github.com/jbenden/rsync/releases
--
You are receiving this mail because:
You are the QA Contact for
https://bugzilla.samba.org/show_bug.cgi?id=12755
Bug ID: 12755
Summary: [patch] Improve execution speed on Windows; with Win32
API calls
Product: rsync
Version: 3.1.3
Hardware: All
OS: Windows 10
https://bugzilla.samba.org/show_bug.cgi?id=12940
Bug ID: 12940
Summary: rsync: -C/--cvs-exclude does not ignore SCM ignore
files (patch)
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
https://bugzilla.samba.org/show_bug.cgi?id=12942
Bug ID: 12942
Summary: Traffic shaping: Make --bwlimit dynamic
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
Severity: normal
https://bugzilla.samba.org/show_bug.cgi?id=12942
--- Comment #2 from kapo...@gmail.com ---
Hi Roland, thanks for your help. I looked at your solution:
export RSYNC_RSH="sh -c 'pv -qL10k | ssh \"\$@\" | (pv -qL11k; kill \$\$)' ssh"
Of course using $$ was
https://bugzilla.samba.org/show_bug.cgi?id=12955
Cun Gong changed:
What|Removed |Added
Attachment #13458|0 |1
is obsolete|
https://bugzilla.samba.org/show_bug.cgi?id=12964
Bug ID: 12964
Summary: Maybe we can add the '--bind-cpu' option
Product: rsync
Version: 3.1.2
Hardware: All
OS: All
Status: NEW
Severity: trivial
https://bugzilla.samba.org/show_bug.cgi?id=12920
Bug ID: 12920
Summary: Invalid path from sender
Product: rsync
Version: 3.1.2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P5
https://bugzilla.samba.org/show_bug.cgi?id=12915
Bug ID: 12915
Summary: --modify-window should default to 1 for fat
filesystems
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
https://bugzilla.samba.org/show_bug.cgi?id=12916
Bug ID: 12916
Summary: when rsync fails to chown, it gives up and does not
set timestamp
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
https://bugzilla.samba.org/show_bug.cgi?id=12915
--- Comment #1 from Kevin Korb ---
This would not actually be very helpful. Going between a *nix style timestamp
and a FAT one has other issues. Especially if your TZ changes or you are in a
TZ where the clock changes twice
https://bugzilla.samba.org/show_bug.cgi?id=12916
--- Comment #1 from Kevin Korb ---
If you mount your FAT filesystems with the quiet option the FAT driver will
just ignore the operations it can't do instead of throwing fatal errors at you.
This will resolve problems in
https://bugzilla.samba.org/show_bug.cgi?id=12915
--- Comment #2 from Ian Kelling ---
> This would not actually be very helpful.
Why? You haven't said. The manual says it's helpful
and it's helpful for me.
--
You are receiving this mail because:
You are the QA Contact for the
https://bugzilla.samba.org/show_bug.cgi?id=12915
--- Comment #5 from Kevin Korb ---
Actually, I looked it up. It wasn't actually my request I had already dealt
with the problem.
This is the ticket from the person I was helping:
https://bugzilla.samba.org/show_bug.cgi?id=12915
--- Comment #3 from Brian K. White ---
(In reply to Ian Kelling from comment #2)
The manuals says useful not helpful. The manual does not say it's good or bad
or recommended or any other value judgement. It only describes it's
https://bugzilla.samba.org/show_bug.cgi?id=12915
--- Comment #4 from Kevin Korb ---
The manual says that with FAT you need --modify-window=2 not 1. But here in
the US for half of the year you need --modify-window=3602 instead. The same
goes for many other locations. The
https://bugzilla.samba.org/show_bug.cgi?id=12915
--- Comment #6 from Ben RUBSON ---
Just to clarify, is FAT32 also impacted and requires --modify-window option, or
only the old one FAT is ? Thx !
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.samba.org/show_bug.cgi?id=12769
--- Comment #3 from Roland Haberkorn ---
Ok, I digged somewhat deeper. I've found a second difference between my two
sources. The one is the original data, the other one is a diffential rsync
backup with hard links.
I then built a
https://bugzilla.samba.org/show_bug.cgi?id=12916
--- Comment #2 from Ian Kelling ---
Great tip. If we can solve it that would be
good too.
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omitting the
https://bugzilla.samba.org/show_bug.cgi?id=12915
--- Comment #8 from Kevin Korb ---
The 3602 problem happens when the clocks change not the entire time the clocks
are different. If you do a daily rsync then rsync will see 1 hour off
timestamps the day after both clock
https://bugzilla.samba.org/show_bug.cgi?id=12915
--- Comment #7 from Ian Kelling ---
> But here in the US for half of the year you need --modify-window=3602 instead.
I think people use vfat because there are a lot of devices out there
like android which require it, and they only
https://bugzilla.samba.org/show_bug.cgi?id=11866
--- Comment #1 from Ben RUBSON ---
I can easily reproduce this dangerous bug.
Both sides running rsync 3.1.2.
# cd /tmp/ && mkdir -p test && cd test && rm -f *
# ssh $usr@$srv "rm -rf /tmp/dst*"
# for i in `seq 0 9`
do
https://bugzilla.samba.org/show_bug.cgi?id=11866
--- Comment #2 from Ben RUBSON ---
Created attachment 13342
--> https://bugzilla.samba.org/attachment.cgi?id=13342=edit
rsync_double_fuzzy_11866
Bug found, patch attached.
Wayne could you please review and commit please ?
https://bugzilla.samba.org/show_bug.cgi?id=12942
--- Comment #1 from roland ---
see https://bugzilla.samba.org/show_bug.cgi?id=7120
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omitting the
https://bugzilla.samba.org/show_bug.cgi?id=12955
Bug ID: 12955
Summary: [patch] Fix rsync -A on AIX
Product: rsync
Version: 3.1.2
Hardware: PPC
OS: AIX
Status: NEW
Severity: normal
Priority: P5
https://bugzilla.samba.org/show_bug.cgi?id=12781
Bug ID: 12781
Summary: rsync library
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P5
https://bugzilla.samba.org/show_bug.cgi?id=12806
--- Comment #4 from Heinz-Willi Wyes ---
I got a personal message from Lars Ellenberg that went also to
samba-b...@samba.org and rsync...@samba.org. He wrote:
--
Calling chmod only on (optimization:
https://bugzilla.samba.org/show_bug.cgi?id=12173
T Yamada changed:
What|Removed |Added
Version|3.0.6 |3.1.1
--- Comment #1
https://bugzilla.samba.org/show_bug.cgi?id=12173
--- Comment #2 from Paul Slootman ---
I think there are more urgent problems than a memory leak of less than 1kB,
which I expect isn't really a leak but memory which isn't freed at the end of
execution but may be used up to that
https://bugzilla.samba.org/show_bug.cgi?id=12173
--- Comment #3 from T Yamada ---
> definitely lost: 4 bytes in 1 blocks
For entire program.
But maybe this priority is low.
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use
https://bugzilla.samba.org/show_bug.cgi?id=12769
--- Comment #2 from Roland Haberkorn ---
I did some further investigation...
First thing to add: The ext4 file systems are hard-linked differential rsync
backups of the real data on XFS.
I changed the testcase by deleting the
https://bugzilla.samba.org/show_bug.cgi?id=12781
--- Comment #1 from Axel Kittenberger ---
I asked exactly this 10 years ago to the mailing list.
The answer was no.
This is not a simple to do.
You could do it, I decided that kind of project would move me too far away from
https://bugzilla.samba.org/show_bug.cgi?id=10738
Ben RUBSON changed:
What|Removed |Added
CC||ben.rub...@gmail.com
https://bugzilla.samba.org/show_bug.cgi?id=12806
Bug ID: 12806
Summary: Deleting in a row of hardlinked snapshots resets file
permissions.
Product: rsync
Version: 3.1.0
Hardware: All
OS: All
https://bugzilla.samba.org/show_bug.cgi?id=12806
--- Comment #1 from Heinz-Willi Wyes ---
Addendum.
Thought that the --inplace option could play the trick. I just employed the
following:
rsync -r --delete --inplace `mktemp -d`/ snapshots/2017-05-28-08-10-11/
But this
https://bugzilla.samba.org/show_bug.cgi?id=12806
--- Comment #2 from Kevin Korb ---
Just use rm -rf to delete a backup.
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omitting the mailing
https://bugzilla.samba.org/show_bug.cgi?id=10738
--- Comment #6 from Ben RUBSON ---
Mmmh however some of the statistics seem to be wrongly calculated.
### Example with tsync 3.1.2 :
Number of files: 8,732 (reg: 7,568, dir: 1,163, link: 1)
Number of created files: 1,232
https://bugzilla.samba.org/show_bug.cgi?id=10738
--- Comment #5 from Ben RUBSON ---
So I just went through the code and found that this feature request is already
implemented.
We just have to use SIGUSR2 and rsync will stop, displaying stats.
kill -USR2
Perfect !
--
You
https://bugzilla.samba.org/show_bug.cgi?id=12806
--- Comment #3 from Heinz-Willi Wyes ---
(In reply to Kevin Korb from comment #2)
I'd like to, but I can't. I set up a local scenario in order to make the
problem most easily reproducible. But the real use case involves
https://bugzilla.samba.org/show_bug.cgi?id=12817
Bug ID: 12817
Summary: [PATCH] Allow daemon itself to chroot
Product: rsync
Version: 3.1.2
Hardware: All
OS: All
Status: NEW
Severity: normal
https://bugzilla.samba.org/show_bug.cgi?id=12817
Ben RUBSON changed:
What|Removed |Added
Attachment #13250|0 |1
is obsolete|
https://bugzilla.samba.org/show_bug.cgi?id=12817
Ben RUBSON changed:
What|Removed |Added
Attachment #13249|0 |1
is obsolete|
https://bugzilla.samba.org/show_bug.cgi?id=12817
Ben RUBSON changed:
What|Removed |Added
Attachment #13248|0 |1
is obsolete|
https://bugzilla.samba.org/show_bug.cgi?id=12819
Bug ID: 12819
Summary: [PATCH] sync() on receiving side for data consistency
Product: rsync
Version: 3.1.2
Hardware: All
OS: All
Status: NEW
Severity:
https://bugzilla.samba.org/show_bug.cgi?id=12838
Bug ID: 12838
Summary: [PATCH] Log sent/received bytes even in case of error
Product: rsync
Version: 3.1.2
Hardware: All
OS: All
Status: NEW
Severity:
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #7 from Ben RUBSON ---
And what about a power failure between 2 ZFS transaction groups ?
Note that my patch simply adds a sync() just after recv_files(), so one sync()
per connection, not per write operation.
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #8 from Brian K. White ---
You tell me, what ABOUT a power failure between 2 zfs, or any other fs
operations?
This does not improve or solve any problem that the fs and all the other layers
aren't already handling.
https://bugzilla.samba.org/show_bug.cgi?id=12806
--- Comment #5 from Heinz-Willi Wyes ---
Lars Ellenberg provided a workaround for the behaviour. Using
rsync -d --delete --super `mktemp -d`/ snapshots/2017-05-26-15-00-53/
plays the trick.
Not sure whether the --super
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #5 from Brian K. White ---
Any program could make this same "just to be safe" argument practically every
time they ever close-on-write for any reason. If they wrote anything, it was
always for some reason, and they
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #6 from Brian K. White ---
Think of it this way, write() already makes a certain promise that it will not
return until it's done it's job, and it will not assert success when it can't.
Essentially the man page for any
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #2 from Ben RUBSON ---
Thank you for your feedback Brian.
I don't have any problem.
I just want to be sure that when client (sender) has finished its transfer, its
data is on server's (receiver) disks, before it
https://bugzilla.samba.org/show_bug.cgi?id=12835
Bug ID: 12835
Summary: Allow --link-dest to link to an optionally unexisting
directory
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #1 from Brian K. White ---
This seems wrong to me. If the OS is failing to manage write buffers and file
access between processes, you would have a lot bigger problems in every process
all through the system, and this
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #3 from Paul Slootman ---
How about just using a post-xfer command on the server side that does 'sync'?
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #4 from Ben RUBSON ---
Yes Paul I thought about it but sync command may not be available if the server
(receiver) is chrooted (for example using patch proposed in #12817).
--
You are receiving this mail because:
https://bugzilla.samba.org/show_bug.cgi?id=12838
--- Comment #1 from Ben RUBSON ---
Mmmmh unfortunately numbers are not correct.
# Sender side (which interrupts the transfer receiving SIGUSR2) :
Total file size: 16.85G bytes
Total transferred file size: 183.38M bytes
https://bugzilla.samba.org/show_bug.cgi?id=12583
Wayne Davison changed:
What|Removed |Added
Resolution|--- |FIXED
https://bugzilla.samba.org/show_bug.cgi?id=12755
--- Comment #2 from Joseph Benden ---
Please disregard the patch attachment as the actual definitive solution and
rather visit my GitHub repository for the current working source and binaries.
If this solution is accepted for
https://bugzilla.samba.org/show_bug.cgi?id=12755
Wayne Davison changed:
What|Removed |Added
Attachment #13169|application/mbox|text/plain
https://bugzilla.samba.org/show_bug.cgi?id=12583
--- Comment #2 from Ben RUBSON ---
Wayne thank you very much !!
Really perfect :)
Many thx !
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid
https://bugzilla.samba.org/show_bug.cgi?id=12769
--- Comment #1 from Roland Haberkorn ---
If you want me to run further testings with other file systems I am totally
willing to produce fake data and run tests. I just haven't done yet because of
my lack of knowledge about the
https://bugzilla.samba.org/show_bug.cgi?id=12769
Bug ID: 12769
Summary: error allocating core memory buffers (code 22)
depending on source file system
Product: rsync
Version: 3.1.0
Hardware: All
OS: Linux
https://bugzilla.samba.org/show_bug.cgi?id=12820
Bug ID: 12820
Summary: rsync always try change owner and group of symlink in
--fake-super mode
Product: rsync
Version: 3.0.9
Hardware: All
OS: All
https://bugzilla.samba.org/show_bug.cgi?id=13044
--- Comment #4 from chd...@gmail.com ---
Communicating with Homebrew today, it's still not clear whether this because of
anything they're doing, or whether rsync will have to do something to
accommodate the combination of Xcode 9 (which only comes
https://bugzilla.samba.org/show_bug.cgi?id=13044
--- Comment #2 from Andrey Gursky ---
utimensat() specified in POSIX.1-2008 (about 9! years ago) has been (at last!)
added in macOS 10.13. So if you've compiled binary using latest Xcode i.e. for
macOS 10.13, then it
https://bugzilla.samba.org/show_bug.cgi?id=13044
--- Comment #3 from Ben RUBSON ---
Nearly off topic, but what is the embedded rsync version in Mac OS 10.13 ?
10.11 still uses 2.6.9 :| ...
Thx !
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.samba.org/show_bug.cgi?id=13044
Bug ID: 13044
Summary: On macOS 10.12.6 with the new Xcode 9, `make check` is
full of failures
Product: rsync
Version: 3.1.2
Hardware: x86
OS: Mac OS X
https://bugzilla.samba.org/show_bug.cgi?id=13044
--- Comment #1 from chd...@gmail.com ---
Hmmm, I can only reproduce this when using Homebrew. I've reported this to
them, so we'll see whether it's their "fault" or whether rsync needs to adjust
for Xcode 9.
--
You are receiving this mail
https://bugzilla.samba.org/show_bug.cgi?id=13044
--- Comment #6 from chd...@gmail.com ---
Homebrew's builds for different macOS versions will use as few versions of
Xcode as possible. Sometimes one version of Xcode is used on two different
macOS VMs with differing macOS versions. Anyway, those
https://bugzilla.samba.org/show_bug.cgi?id=13044
--- Comment #5 from Andrey Gursky ---
> Xcode 9 (which only comes with a 10.13 SDK)
I guess you obviously will not be able to compile programs for other macOS
versions with such Xcode 9. Unless you install the appropriate
https://bugzilla.samba.org/show_bug.cgi?id=12417
Wayne Davison changed:
What|Removed |Added
Resolution|--- |WORKSFORME
https://bugzilla.samba.org/show_bug.cgi?id=11656
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.samba.org/show_bug.cgi?id=11866
Wayne Davison changed:
What|Removed |Added
Resolution|--- |FIXED
https://bugzilla.samba.org/show_bug.cgi?id=12568
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.samba.org/show_bug.cgi?id=11866
--- Comment #5 from Ben RUBSON ---
Thank you very much for the merge Wayne !
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omitting the
https://bugzilla.samba.org/show_bug.cgi?id=11571
Wayne Davison changed:
What|Removed |Added
Resolution|--- |FIXED
https://bugzilla.samba.org/show_bug.cgi?id=11338
--- Comment #2 from James Stevenson ---
I seem to see the same crash. Here is some additional details with symbols. It
seems to happen during network timeouts.
#0 0x7fcc2e167b05 in utf8_internal_loop (step=0x560710d73f90,
https://bugzilla.samba.org/show_bug.cgi?id=10776
--- Comment #2 from James Stevenson ---
This looks like a possible duplicate of
https://bugzilla.samba.org/show_bug.cgi?id=11338
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use
https://bugzilla.samba.org/show_bug.cgi?id=13082
Bug ID: 13082
Summary: [REQ] Hardware / SSE based MD5 operations
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
Severity: normal
https://bugzilla.samba.org/show_bug.cgi?id=13061
Bug ID: 13061
Summary: File lost on case-insensitive file system
Product: rsync
Version: 3.1.3
Hardware: All
OS: Windows 7
Status: NEW
Severity: major
https://bugzilla.samba.org/show_bug.cgi?id=13061
--- Comment #1 from Kevin Korb ---
Are you saying that it deleted a file AFTER saying "IO error encountered --
skipping file deletion"?
Maybe you need some --itemize-changes to make sure. Unfortunately, this is a
limitation
https://bugzilla.samba.org/show_bug.cgi?id=13061
--- Comment #2 from t...@towo.net ---
Actually, I was too eager minimizing the test case, sorry.
I can only reproduce it reliably with additional options -vltoD :
rsync -vrltoD --delete-after src /backup
Also sorry for the bogus error message,
https://bugzilla.samba.org/show_bug.cgi?id=13061
--- Comment #3 from Kevin Korb ---
That makes even less sense. Rsync doesn't do anything to the source at all
unless --remove-source-files and it only does that after it successfully
transfers a file.
--
You are receiving
https://bugzilla.samba.org/show_bug.cgi?id=13061
--- Comment #5 from Kevin Korb ---
OK, now I understand what is going on. It is a 2-part problem...
Rsync sees the source file as new because it does not exist in the target but
it fails to copy the file because the name
https://bugzilla.samba.org/show_bug.cgi?id=13061
--- Comment #4 from t...@towo.net ---
The file /backup/src/vivaldi is deleted, not src/Vivaldi
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omitting the mailing
https://bugzilla.samba.org/show_bug.cgi?id=10715
Pierre-Olivier Mercier changed:
What|Removed |Added
CC|
https://bugzilla.samba.org/show_bug.cgi?id=12817
Wayne Davison changed:
What|Removed |Added
Resolution|--- |FIXED
https://bugzilla.samba.org/show_bug.cgi?id=12817
--- Comment #5 from Ben RUBSON ---
Many thanks Wayne for having reworked & merged it !
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omitting
https://bugzilla.samba.org/show_bug.cgi?id=10719
--- Comment #1 from lonerr ---
Three years later, any updates? :)
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To
https://bugzilla.samba.org/show_bug.cgi?id=10719
Wayne Davison changed:
What|Removed |Added
Resolution|--- |FIXED
https://bugzilla.samba.org/show_bug.cgi?id=13071
Bug ID: 13071
Summary: [PATCH] Allow --partial-dir with --inplace
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
Severity: normal
https://bugzilla.samba.org/show_bug.cgi?id=7123
--- Comment #7 from Ben RUBSON ---
I should have a look at this.
This would complete my work in https://bugzilla.samba.org/show_bug.cgi?id=13071
to help dealing with big files.
--
You are receiving this mail because:
You are
https://bugzilla.samba.org/show_bug.cgi?id=11866
--- Comment #3 from Ben RUBSON ---
Hi,
Could it be possible to merge this please ?
It's really tiny (one character) and easily understandable :)
And it avoids silent data loss !
Thank you very much !
Ben
--
You are
https://bugzilla.samba.org/show_bug.cgi?id=13083
Bug ID: 13083
Summary: [PATCH] Use both partial file + basis file
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
Severity: normal
https://bugzilla.samba.org/show_bug.cgi?id=7123
--- Comment #8 from Ben RUBSON ---
See https://bugzilla.samba.org/show_bug.cgi?id=13083 for a patch !
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to
1 - 100 of 679 matches
Mail list logo