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 for the
https://bugzilla.samba.org/show_bug.cgi?id=6741
--- Comment #6 from Marc Aurèle La France ---
Created attachment 18425
--> https://bugzilla.samba.org/attachment.cgi?id=18425&action=edit
rsync stdout filter
vee too
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
https://bugzilla.samba.org/show_bug.cgi?id=3693
--- Comment #12 from Ben Millwood ---
hi folks, I've run into this problem in a couple of cases that I think haven't
been mentioned so far:
- Every month I rsync my boot disk to an external disk and then take a ZFS
copy-on-write snapshot of the ext
https://bugzilla.samba.org/show_bug.cgi?id=2294
--- Comment #41 from Mihnea-Costin Grigore ---
The discussion about file systems like ZFS/BTRFS/etc. and their various
snapshot mechanisms is off-topic relative to this feature request, since they
are very different technologies used for different p
https://bugzilla.samba.org/show_bug.cgi?id=6741
--- Comment #5 from Marc Aurèle La France ---
Created attachment 18263
--> https://bugzilla.samba.org/attachment.cgi?id=18263&action=edit
rsync stdout filter
Just something I've come up with to work around this issue. Not perfect but
does the jo
https://bugzilla.samba.org/show_bug.cgi?id=15585
Bug ID: 15585
Summary: rsync ends still with error 22 when try to deleting
many files
Product: rsync
Version: 3.2.0
Hardware: All
OS: All
Status:
https://bugzilla.samba.org/show_bug.cgi?id=2294
--- Comment #39 from andy ---
> This feature request is so old it has lost relavence because btrfs/zfs/etc
> are more optimal backup solutions than rsync.
Funny I am doing exactly this, but I came to rsync looking for a backup for
when ZFS fails.
https://bugzilla.samba.org/show_bug.cgi?id=15546
Bug ID: 15546
Summary: disable of sorting when files to transfer is fed via
--files-from
Product: rsync
Version: 3.2.0
Hardware: All
OS: All
Statu
https://bugzilla.samba.org/show_bug.cgi?id=12806
--- Comment #7 from Aryo Da ---
I think this a severe bug for all backup use cases of rsync that take a full
snapshot with permissions (--perms) by creating hardlinks to unchanged files +
copies of changed files (--link-dest):
-> Whenever an old s
https://bugzilla.samba.org/show_bug.cgi?id=12806
--- Comment #6 from Aryo Da ---
Created attachment 18117
--> https://bugzilla.samba.org/attachment.cgi?id=18117&action=edit
MRE (minimal reproducible example) as bash script to reproduce the bug
Rename to "setup.sh" and make it executable...
--
https://bugzilla.samba.org/show_bug.cgi?id=7809
--- Comment #6 from Jeffrey Simon ---
3. The script does not work from launchd running as root.
I should have given the failure mode, which is the following:
rsync: opendir "/Volumes/Backup1/." failed: Operation not permitted (1)
rsync error: some
https://bugzilla.samba.org/show_bug.cgi?id=7809
--- Comment #5 from Jeffrey Simon ---
"Excludes are relative to the source dir". Are you saying that the excludes
should be --exclude=.DocumentRevisions-V100 --exclude=.TemporaryItems
--exclude=.Trashes?
That is a rhetorical question, because I no
https://bugzilla.samba.org/show_bug.cgi?id=7809
--- Comment #4 from Kevin Korb ---
Your excludes aren't working because excludes are relative to the source dir
not /.
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid o
https://bugzilla.samba.org/show_bug.cgi?id=7809
--- Comment #3 from Jeffrey Simon ---
One other point to follow up my first post of 2023-07-21:
None of these issues occurred on macOS Monterey 12.4.x
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use repl
https://bugzilla.samba.org/show_bug.cgi?id=7809
--- Comment #2 from Jeffrey Simon ---
This is an old ticket, but I am getting the same or similar problem in 2023
with rsync on macOS Ventura 13.4.1.
Here is the first attempt and partial results:
rsync -av --delete /Volumes/Backup1/ /Volumes/Ba
https://bugzilla.samba.org/show_bug.cgi?id=15393
Bug ID: 15393
Summary: rsync attempts to set extended attributes while in
dry-run
Product: rsync
Version: 3.2.0
Hardware: All
OS: All
Status: NEW
https://bugzilla.samba.org/show_bug.cgi?id=5124
--- Comment #12 from Paulo Marques ---
Using multiple connections also helps when you have LACP network links, which
are relatively common in data center setups to have both redundancy and
increased bandwidth.
If you have two 1Gbps links aggregated
https://bugzilla.samba.org/show_bug.cgi?id=15335
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=15335
Bug ID: 15335
Summary: Environment variables in remote host's path do not
resolve properly
Product: rsync
Version: 3.2.0
Hardware: x86
OS: Linux
S
https://bugzilla.samba.org/show_bug.cgi?id=10170
--- Comment #6 from Brian J. Murrell ---
Does this --reflink feature have any parity/functionality with --link-dest,
which is often used in "snapshot" style [i.e. daily] backup scripts on
non-snapshottable filesystems such as XFS?
XFS supports CO
https://bugzilla.samba.org/show_bug.cgi?id=8690
--- Comment #1 from Björn Jacke ---
AIXC type ACLs are incompatible with other ACLs like thised used on Linux. The
only ACLs which are standardized are actually NFS4 ACLs. Rsync doesn't really
support those unfortunately, yet. Linux also lacks suppo
https://bugzilla.samba.org/show_bug.cgi?id=15163
--- Comment #6 from roland ---
nobody has a clue?
i think proper rsync timeout handling is important.
i have had whole nightly backup procedures hung for the whole night because
rsync got stuck and didn't get timeout, i.e. machines did not get pr
https://bugzilla.samba.org/show_bug.cgi?id=15254
Frank B changed:
What|Removed |Added
Resolution|WORKSFORME |FIXED
--- Comment #10 from Frank B ---
Ok, so y
https://bugzilla.samba.org/show_bug.cgi?id=15254
--- Comment #9 from Wayne Davison ---
The combo of -I with -u briefly changed to be broken but it was fixed. The -u
option means that older files on the sender are ignored. -I means that files
with the same date are TRANSFERRED. When that was not
https://bugzilla.samba.org/show_bug.cgi?id=15254
Wayne Davison changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|REOPENED
https://bugzilla.samba.org/show_bug.cgi?id=15254
--- Comment #8 from Frank B ---
Quick addition:
You can say it's a "corner case", a result of wrong assumptions regarding u/I
or a weird usecase but you can't say "nothing has changed" since that clearly
isn't true.
The question is: is uI support
https://bugzilla.samba.org/show_bug.cgi?id=15254
Frank B changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WORKSFORME
https://bugzilla.samba.org/show_bug.cgi?id=15254
--- Comment #7 from Frank B ---
Yes, it has. The crontab was unchanged for months and directly after the update
of rsync via apt, it started performing full replications. It's clearly a
result of the new binary.
--
You are receiving this mail bec
https://bugzilla.samba.org/show_bug.cgi?id=15254
--- Comment #6 from Kevin Korb ---
I can confirm that something did change...
# mkdir /tmp/src /tmp/dest
# touch /tmp/src/a /tmp/src/b /tmp/src/c
# rsync -vai /tmp/src/ /tmp/dest/
sending incremental file list
.d..t.. ./
>f+ a
>f++
https://bugzilla.samba.org/show_bug.cgi?id=15254
--- Comment #5 from Kevin Korb ---
I had the same knee jerk reaction as Wayne to this question. -I means re-copy
everything (or at least re-diff everything unless --whole-file). But I never
attempted to mix it with -u so I held my tongue. Is it
https://bugzilla.samba.org/show_bug.cgi?id=15254
--- Comment #4 from Wayne Davison ---
No it didn't.
--
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 unsubscribe or change options: https:
https://bugzilla.samba.org/show_bug.cgi?id=15254
--- Comment #3 from Frank B ---
The behavior still changed as this was working for months and clearly changed
directly after upgrading to the new binary but it's okay for me. Looks like the
I should have been l in my case due to a copy and paste is
https://bugzilla.samba.org/show_bug.cgi?id=15254
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=15254
--- Comment #1 from Frank B ---
rsync --version
rsync version 3.2.3 protocol version 31
--
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=15254
Bug ID: 15254
Summary: rsync performs full replication with option -I since
last upgrade to version 3.2.3 protocol version 31
Product: rsync
Version: 3.2.0
Hardware: x64
https://bugzilla.samba.org/show_bug.cgi?id=13082
--- Comment #6 from Andrew Bartlett ---
Samba 4.11 moved to GnuTLS for our MD5 and other hash operations, and so uses
any hardware optimisation available there.
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Pleas
https://bugzilla.samba.org/show_bug.cgi?id=12964
--- Comment #1 from Stefan Metzmacher ---
On Linux you can use taskset (in combination with nice and ionice)...
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omittin
https://bugzilla.samba.org/show_bug.cgi?id=15163
--- Comment #5 from roland ---
apparently, this is causing the problem:
if (am_receiver) {
return;
}
if i comment out the return statement, things work again.
@wayne, what is the reason that timeout checking is
https://bugzilla.samba.org/show_bug.cgi?id=15163
--- Comment #4 from roland ---
here with debug=all
working correctly
# /root/rsync/rsync-3.2.5/rsync -avi --timeout=5 --exclude='/proc'
--exclude='/dev/' --exclude='/sys' --debug=all --msgs2stderr
root@172.20.37.189:/iscsipool /zfspool/backup/1
https://bugzilla.samba.org/show_bug.cgi?id=15163
--- Comment #3 from roland ---
ah, getting a clue
in io.c
static void check_timeout(BOOL allow_keepalive, int keepalive_flags)
{
time_t t, chk;
/* On the receiving side, the generator is now the one that decides
* when a
https://bugzilla.samba.org/show_bug.cgi?id=15163
--- Comment #2 from roland ---
here is another bugreport, where timeout is not effective/working
https://bugzilla.redhat.com/show_bug.cgi?id=1944132
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply
https://bugzilla.samba.org/show_bug.cgi?id=15163
--- Comment #1 from roland ---
here is some strace from the backup host to show the difference
if i set timeout=60 , rsyncing "root@172.20.37.189:/" hangs forever:
08:25:30 select(4, [3], [], [3], {tv_sec=30, tv_usec=0}) = 1 (in [3], left
{tv_se
https://bugzilla.samba.org/show_bug.cgi?id=15163
Bug ID: 15163
Summary: rsync timeout non-effective
Product: rsync
Version: 3.2.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P5
https://bugzilla.samba.org/show_bug.cgi?id=15122
--- Comment #3 from Aditya Basu ---
Apologies for the late response.
It is definitely a bad idea to mix multi-case systems. However, note that even
copying between case-honoring systems can have similar consequences, for ex.
case-insensitive (icas
https://bugzilla.samba.org/show_bug.cgi?id=15122
--- Comment #2 from Wayne Davison ---
BTW, what happens in the test case you provided is that the generator creates
TOPDIR and then TOPDIR/secret dirs before asking the sender to start a transfer
of TOPDIR/secret/config. It then goes on to notice
https://bugzilla.samba.org/show_bug.cgi?id=15122
--- Comment #1 from Wayne Davison ---
Yes, it's always bad to copy from a case-honoring filesystem to a case-ignoring
filesystem as the filenames can overlap. This is something that the user just
shouldn't do, as rsync is written to handle case-ho
https://bugzilla.samba.org/show_bug.cgi?id=5642
--- Comment #1 from c.bu...@posteo.jp ---
As a maintainer of one of that rsync-using-GUIs I would find that also very
nice.
But I don't see an advantage with XML. To complex and not human readable. Cost
a lot of resources (think about sustainability
https://bugzilla.samba.org/show_bug.cgi?id=15154
Bug ID: 15154
Summary: manpage: Describe default behavior in context of
--old-args/--protect-args
Product: rsync
Version: 3.2.0
Hardware: All
OS: All
https://bugzilla.samba.org/show_bug.cgi?id=15122
Bug ID: 15122
Summary: Potential vulnerability: rsync creates files outside
the target directory
Product: rsync
Version: 3.2.0
Hardware: All
OS: Linux
https://bugzilla.samba.org/show_bug.cgi?id=13463
--- Comment #5 from Simon Deziel ---
The `Restart=on-failure` option was added in
https://github.com/WayneD/rsync/commit/d41bb98c09bf0b999c4eee4e2125c7e5d0747ec4
This should paper over the problem of late showing IPv6 addresses due to DAD
taking t
https://bugzilla.samba.org/show_bug.cgi?id=13463
--- Comment #4 from Simon Deziel ---
Since rsyncd exits with error code 10 ("Error in socket I/O") there are two
possible ways to improve the systemd unit:
[Service]
...
RestartForceExitStatus=10
Or:
[Service]
...
Restart=on-failure
Both shoul
https://bugzilla.samba.org/show_bug.cgi?id=13463
--- Comment #3 from Andreas Hasenack ---
Thanks for all the opinions. I have one remaining issue, and that is with
"systemctl start rsync.service" not detecting the failure right away.
The systemd unit file calls rsync like this:
[Service]
ExecSt
https://bugzilla.samba.org/show_bug.cgi?id=8682
--- Comment #6 from Joachim Wagner ---
The "echo > sourcefile" workaround seems to not trigger an error, at least not
straight away and at least on XFS, but instead speeds up the operation and
stops writing more data to the target file. Observation
ot to a "warning" level before memoryd started
killing things.
If that's what you're seeing, it's not an rsync bug, it's a bug in macOS.
Mike
> On Jan 27, 2022, at 11:26AM, just subscribed for rsync-qa from bugzilla via
> rsync wrote:
>
> h
https://bugzilla.samba.org/show_bug.cgi?id=14962
Bug ID: 14962
Summary: Crash/restart using rsync 3.2.3 on M1 Mac
Product: rsync
Version: 3.2.0
Hardware: All
OS: All
Status: NEW
Severity: normal
https://bugzilla.samba.org/show_bug.cgi?id=11879
Wayne Davison changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugzilla.samba.org/show_bug.cgi?id=14916
Bug ID: 14916
Summary: --times act like a skip switch if --compare-dest is
used
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
https://bugzilla.samba.org/show_bug.cgi?id=10629
--- Comment #2 from Kevin Korb ---
Since find is one of the few utilities that actually corrects for symlink loops
you can use it as a workaround. Something like:
cd /source/path ; find -L . -print | rsync ... --copy-links --files-from=- ./
/tar
https://bugzilla.samba.org/show_bug.cgi?id=10629
Timothee Besset changed:
What|Removed |Added
CC||tt...@ttimo.net
--- Comment #1 from Timo
https://bugzilla.samba.org/show_bug.cgi?id=12769
--- Comment #14 from Roland Haberkorn ---
After the new version made it into my system I can confirm it works like a
charm. Many thanks for the effort.
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use rep
https://bugzilla.samba.org/show_bug.cgi?id=14798
Bug ID: 14798
Summary: Metadata traffic --- uncompressed with -z, interaction
with --bwlimit and ssh compression
Product: rsync
Version: 3.1.3
Hardware: All
O
https://bugzilla.samba.org/show_bug.cgi?id=14683
--- Comment #2 from Ciprian Dorin Craciun ---
(In reply to Ciprian Dorin Craciun from comment #1)
Trying to `strace` what `rsync` does in my OpenAFS use-case I've found that the
only syscals invoked by `rysync` (and pertaining to the file in quest
https://bugzilla.samba.org/show_bug.cgi?id=14683
--- Comment #1 from Ciprian Dorin Craciun ---
I've encountered a similar situation, but with OpenAFS, which for some reason
reports the protection for symlinks as `rwxr-xr-x`.
Thus using `rsync` with `--perms` and targeting an OpenAFS folder fails
https://bugzilla.samba.org/show_bug.cgi?id=14683
Bug ID: 14683
Summary: failed to set permissions on symlinks; need
`--omit-link-permissions` option
Product: rsync
Version: 3.2.0
Hardware: All
OS: All
https://bugzilla.samba.org/show_bug.cgi?id=2294
--- Comment #38 from Claudius Ellsel ---
This basically is some personal preference. I know that I can do this on btrfs
(which is used on the system I want to back up from), also pretty easy with
tools like snapper. Maybe it would be feasible to do
https://bugzilla.samba.org/show_bug.cgi?id=2294
--- Comment #37 from elatl...@gmail.com ---
The btrfs equivalent is a bit more rough but (link for rename);
#./btrfs-snapshots-diff.py -sb -p /media/btrfs/v_1/s_1 -c /media/btrfs/v_1/s_2
| grep -E path=. | grep -v utimes | tail -n +2
link;path=fileB
https://bugzilla.samba.org/show_bug.cgi?id=2294
--- Comment #36 from elatl...@gmail.com ---
(In reply to Claudius Ellsel from comment #35)
> This is going off-topic
On such an old bug with modern workarouds I think it's worth talking about.
> backup drive is NTFS currently, which would complicat
https://bugzilla.samba.org/show_bug.cgi?id=2294
--- Comment #35 from Claudius Ellsel ---
(In reply to elatllat from comment #34)
>Yes you can easily access files on a COW-FS backup; it's a file system, that's
>>what it's for.
This is going off-topic, but my backup drive is NTFS currently, which
https://bugzilla.samba.org/show_bug.cgi?id=2294
--- Comment #34 from elatl...@gmail.com ---
(In reply to Claudius Ellsel from comment #33)
Yes you can easily access files on a COW-FS backup; it's a file system, that's
what it's for.
If you want to review changes before backup you can just diff or
https://bugzilla.samba.org/show_bug.cgi?id=2294
--- Comment #33 from Claudius Ellsel ---
Hm, those backups won't work on file level, though afaik. Thus I cannot easily
access files on a backup drive for example. Also I want to use this as some
kind of confirm stage a bit like committing with git
https://bugzilla.samba.org/show_bug.cgi?id=2294
--- Comment #32 from elatl...@gmail.com ---
(In reply to Claudius Ellsel from comment #31)
Yes any COW FS with "send/receive" will have inherent rename handaling, and
will be faster than rsync because the diffs are inherent. With zfs one can even
hav
https://bugzilla.samba.org/show_bug.cgi?id=2294
--- Comment #31 from Claudius Ellsel ---
To me and others it still seems relevant.
I have to admit though that I haven't looked much into other solutions for
backups like btrfs send/receive commands. I suppose that were the ones you
meant? Note tha
https://bugzilla.samba.org/show_bug.cgi?id=8367
Claudius Ellsel changed:
What|Removed |Added
CC||claudius.ell...@live.de
--- Comment #7 fr
https://bugzilla.samba.org/show_bug.cgi?id=2294
--- Comment #30 from elatl...@gmail.com ---
This feature request is so old it has lost relavence because btrfs/zfs/etc are
more optimal backup solutions than rsync.
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Ple
https://bugzilla.samba.org/show_bug.cgi?id=10263
--- Comment #3 from Claudius Ellsel ---
I have to admit that I only skimmed through the description. There is
definitely some more to this than in the other bug.
Have a look at https://bugzilla.samba.org/show_bug.cgi?id=2294#c14 though. The
patche
https://bugzilla.samba.org/show_bug.cgi?id=10263
--- Comment #2 from Haravikk ---
It's certainly similar but I wouldn't say a direct duplicate; 2294 is
requesting detection of move/rename *somehow* which is a tricky proposition
(especially with rsync defaulting towards incremental send rather tha
https://bugzilla.samba.org/show_bug.cgi?id=2294
--- Comment #29 from Claudius Ellsel ---
As another motivation for this, I use rsync for backups and would like to be
able to see whether files have just been renamed or were deleted and some
others newly created (which currently cannot be distingui
https://bugzilla.samba.org/show_bug.cgi?id=2294
Claudius Ellsel changed:
What|Removed |Added
CC||claudius.ell...@live.de
--- Comment #28 f
https://bugzilla.samba.org/show_bug.cgi?id=10263
Claudius Ellsel changed:
What|Removed |Added
CC||claudius.ell...@live.de
--- Comment #1 f
https://bugzilla.samba.org/show_bug.cgi?id=14529
--- Comment #1 from Andras Korn ---
It's completely fine if using this "database" in writable modules implies or
requires `max connections = 1` to avoid concurrency/locking issues.
--
You are receiving this mail because:
You are the QA Contact fo
https://bugzilla.samba.org/show_bug.cgi?id=14529
Bug ID: 14529
Summary: Please add option to save metadata to single file to
speed up backups
Product: rsync
Version: 3.2.0
Hardware: All
OS: All
S
https://bugzilla.samba.org/show_bug.cgi?id=14463
--- Comment #4 from Wayne Davison ---
The pre-release patches aren't guaranteed to be backward compatible, and in
this case the bits that were used in a couple different patches actually
conflicted with each other. So, when --atimes was promoted it
https://bugzilla.samba.org/show_bug.cgi?id=14463
--- Comment #3 from bumkick...@yahoo.com ---
It's not a trivial exercise to upgrade the rsync version on the target system,
so it would be useful if there was some kind of "back patch" available
| suspect there might be others with similar issues
https://bugzilla.samba.org/show_bug.cgi?id=14463
--- Comment #2 from bumkick...@yahoo.com ---
(In reply to Wayne Davison from comment #1)
What should we do instead to keep the same functionality?
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-al
https://bugzilla.samba.org/show_bug.cgi?id=14463
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=14463
Bug ID: 14463
Summary: rsync 3.2.2 server protocol error
Product: rsync
Version: 3.2.0
Hardware: All
OS: FreeBSD
Status: NEW
Severity: normal
Prio
https://bugzilla.samba.org/show_bug.cgi?id=11979
--- Comment #3 from Wayne Davison ---
Nope, that's the whole point.
--
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 unsubscribe or change
https://bugzilla.samba.org/show_bug.cgi?id=5728
Wayne Davison changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=5820
Wayne Davison changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=6741
Wayne Davison changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=6928
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=6821
Wayne Davison changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=3465
--- Comment #8 from Wayne Davison ---
Jeff: the command you mention already works fine, since --files-from is not
involved.
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to av
https://bugzilla.samba.org/show_bug.cgi?id=10405
Wayne Davison changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://bugzilla.samba.org/show_bug.cgi?id=11609
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=13660
--- Comment #2 from Jonas Eberle ---
Thanks. Could you point to a commit where this has been changed please?
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omitting t
https://bugzilla.samba.org/show_bug.cgi?id=8990
Wayne Davison changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|ASSIGNED
https://bugzilla.samba.org/show_bug.cgi?id=8856
Wayne Davison changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://bugzilla.samba.org/show_bug.cgi?id=12153
Wayne Davison changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
https://bugzilla.samba.org/show_bug.cgi?id=10675
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 688 matches
Mail list logo
