https://bugzilla.samba.org/show_bug.cgi?id=13104
Bug ID: 13104
Summary: NULL deref do_server_sender when argc=0
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
Severity: normal
Pr
https://bugzilla.samba.org/show_bug.cgi?id=13105
Bug ID: 13105
Summary: 1byte heap overflow in sanitize_path
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
Severity: normal
Prior
https://bugzilla.samba.org/show_bug.cgi?id=13109
Bug ID: 13109
Summary: rsync hangs during transfer of many small files
Product: rsync
Version: 3.1.2
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
https://bugzilla.samba.org/show_bug.cgi?id=13104
Wayne Davison changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugzilla.samba.org/show_bug.cgi?id=13105
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=13112
Bug ID: 13112
Summary: receive_xattr heap overread with non null terminated
name and xattr filter
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
https://bugzilla.samba.org/show_bug.cgi?id=13113
Bug ID: 13113
Summary: receive_xattr heap overflow when prepending
RSYNC_PREFIX
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
https://bugzilla.samba.org/show_bug.cgi?id=13112
--- Comment #1 from jeriko@gmx.us ---
This issue can also be reached in 3.1.2, but through a different path as the
earlier version doesn't have an xattr filter. I believe the same fix for 3.1.3
would work for 3.1.2 (using read_sbuf) If I should
https://bugzilla.samba.org/show_bug.cgi?id=13115
Bug ID: 13115
Summary: .yo sources incompatible with current yodl version
Product: rsync
Version: 3.1.2
Hardware: All
OS: All
Status: NEW
Severity: normal
https://bugzilla.samba.org/show_bug.cgi?id=12498
--- Comment #1 from Ben RUBSON ---
Created attachment 13748
--> https://bugzilla.samba.org/attachment.cgi?id=13748&action=edit
Do fuzzy only when needed
Here's a patch for this issue. Thx !
--
You are receiving this mail because:
You are the Q
https://bugzilla.samba.org/show_bug.cgi?id=13109
--- Comment #1 from Hansjoerg Lipp ---
Created attachment 13756
--> https://bugzilla.samba.org/attachment.cgi?id=13756&action=edit
zip archive of the test case
Attached a zip archive of the test case to make reproducing the problem easier:
unzi
https://bugzilla.samba.org/show_bug.cgi?id=13112
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=13115
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=11414
--- Comment #2 from Michal Ruprich ---
I stumbled upon this bug and I have a question. I get the chgrp error even when
running the daemon as root.
#ps -aux | grep rsync
root 18486 0.0 0.0 114696 568 ?Ss 09:41 0:00 rsync --daem
https://bugzilla.samba.org/show_bug.cgi?id=11414
--- Comment #3 from Kevin Korb ---
Oops, I replied to this on the email list instead of the bugzilla. Sorry for
the extra noise...
It isn't running as root (it probably never should). It is launched as
root. It is running as tester:tester just
https://bugzilla.samba.org/show_bug.cgi?id=13109
--- Comment #2 from Hansjoerg Lipp ---
Created attachment 13760
--> https://bugzilla.samba.org/attachment.cgi?id=13760&action=edit
Simplified test case
I could simplify the test case even further, the attached test script does not
even need any
https://bugzilla.samba.org/show_bug.cgi?id=11414
--- Comment #4 from Michal Ruprich ---
I see. I never looked at the ps aux output during the transfer so all I saw was
the user that launched the daemon. So I assume that the chgrp error that occurs
without the fake super option is the correct beha
https://bugzilla.samba.org/show_bug.cgi?id=11414
--- Comment #5 from Michal Ruprich ---
There is one more thing that doesn't make sense to me. Even if the operation of
changing the group fails, why doesn't rsync finish other things under the -a
option. For instance the permissions of the original
https://bugzilla.samba.org/show_bug.cgi?id=11414
--- Comment #6 from Kevin Korb ---
There was a change made in 3.1.0...
- Added a way for more than one group to be specified in the daemon's
config file, including a way to specify that you want all of the
specified user's groups w
https://bugzilla.samba.org/show_bug.cgi?id=11414
--- Comment #7 from Michal Ruprich ---
Thank you Kevin. This makes sense.
--
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
https://bugzilla.samba.org/show_bug.cgi?id=13139
Bug ID: 13139
Summary: Formatted output turned off when --link-dest is used
Product: rsync
Version: 3.1.2
Hardware: All
OS: All
Status: NEW
Severity: normal
https://bugzilla.samba.org/show_bug.cgi?id=7757
--- Comment #6 from roland ---
i can confirm this still exists.
needed to adjust the timeout as it times out on our database backup file (90gb)
when there is higher load on the database server.
--
You are receiving this mail because:
You are the
https://bugzilla.samba.org/show_bug.cgi?id=13147
Bug ID: 13147
Summary: inconsistent behaviour regaring vanished files
information
Product: rsync
Version: 3.0.9
Hardware: x64
OS: Mac OS X
Status:
https://bugzilla.samba.org/show_bug.cgi?id=13147
--- Comment #1 from roland ---
i searched into this a little bit and it`s not a problem with differing rsync
versions, it also happens with rsync 3.1.2 (linux) -> rsync 3.1.2 (osx)
what i found is, that rsync 3.1.2 behaves correctly when run on os
https://bugzilla.samba.org/show_bug.cgi?id=13147
--- Comment #2 from roland ---
it`s also no linux->osx interacting issue, the problem also appears when doing
rsync on osx via ssh/localhost.
but why ?
ssh & osx does handle stdout and stdout correctly, as shown here:
gonzo:tmp root# ssh root@
https://bugzilla.samba.org/show_bug.cgi?id=13147
--- Comment #3 from roland ---
apparently, ssh as a transport is the culprit, as it doesn`t happen with rsync
in daemon mode.
i found some osx related ticket on "stderr/stdout merge" (
https://github.com/ansible/ansible/issues/14960 )
after furt
https://bugzilla.samba.org/show_bug.cgi?id=13147
--- Comment #4 from roland ---
mhh, if the error is not a warning but an error, the offending file is shown
(for the warning of vanished files, the warning itself goes to stderr but the
vanished filename goes to stdout). but only on OSX
why that d
https://bugzilla.samba.org/show_bug.cgi?id=10357
--- Comment #11 from Michal Ruprich ---
I ran into a different problem with xattrs tests. It seems that the
--fake-super option sets not only all the xattr like user.short, user.long etc.
that are set in the test, but also it adds
user.rsync.secu
https://bugzilla.samba.org/show_bug.cgi?id=2957
--- Comment #28 from devuran...@gmx.net ---
There are a lot of bugreports related to rsync hanging mysteriously, some of
which may be duplicates of each other:
https://bugzilla.samba.org/show_bug.cgi?id=1442
https://bugzilla.samba.org/show_bug.cgi?i
https://bugzilla.samba.org/show_bug.cgi?id=11166
--- Comment #2 from devuran...@gmx.net ---
There are a lot of bugreports related to rsync hanging mysteriously, some of
which may be duplicates of each other:
https://bugzilla.samba.org/show_bug.cgi?id=1442
https://bugzilla.samba.org/show_bug.cgi?i
https://bugzilla.samba.org/show_bug.cgi?id=1442
--- Comment #13 from devuran...@gmx.net ---
There are a lot of bugreports related to rsync hanging mysteriously, some of
which may be duplicates of each other:
https://bugzilla.samba.org/show_bug.cgi?id=1442
https://bugzilla.samba.org/show_bug.cgi?i
https://bugzilla.samba.org/show_bug.cgi?id=10518
--- Comment #9 from devuran...@gmx.net ---
There are a lot of bugreports related to rsync hanging mysteriously, some of
which may be duplicates of each other:
https://bugzilla.samba.org/show_bug.cgi?id=1442
https://bugzilla.samba.org/show_bug.cgi?i
https://bugzilla.samba.org/show_bug.cgi?id=9164
--- Comment #1 from devuran...@gmx.net ---
There are a lot of bugreports related to rsync hanging mysteriously, some of
which may be duplicates of each other:
https://bugzilla.samba.org/show_bug.cgi?id=1442
https://bugzilla.samba.org/show_bug.cgi?id
https://bugzilla.samba.org/show_bug.cgi?id=12732
--- Comment #2 from devuran...@gmx.net ---
There are a lot of bugreports related to rsync hanging mysteriously, some of
which may be duplicates of each other:
https://bugzilla.samba.org/show_bug.cgi?id=1442
https://bugzilla.samba.org/show_bug.cgi?i
https://bugzilla.samba.org/show_bug.cgi?id=10092
--- Comment #5 from devuran...@gmx.net ---
Could this be a duplicate of bug #1442?
There are a lot of bugreports related to rsync hanging mysteriously, some of
which may be duplicates of each other:
https://bugzilla.samba.org/show_bug.cgi?id=1442
https://bugzilla.samba.org/show_bug.cgi?id=13109
--- Comment #3 from devuran...@gmx.net ---
There are a lot of bugreports related to rsync hanging mysteriously, some of
which may be duplicates of each other:
https://bugzilla.samba.org/show_bug.cgi?id=1442
https://bugzilla.samba.org/show_bug.cgi?i
https://bugzilla.samba.org/show_bug.cgi?id=10950
--- Comment #1 from devuran...@gmx.net ---
There are a lot of bugreports related to rsync hanging mysteriously, some of
which may be duplicates of each other:
https://bugzilla.samba.org/show_bug.cgi?id=1442
https://bugzilla.samba.org/show_bug.cgi?i
https://bugzilla.samba.org/show_bug.cgi?id=10035
--- Comment #7 from devuran...@gmx.net ---
There are a lot of bugreports related to rsync hanging mysteriously, some of
which may be duplicates of each other:
https://bugzilla.samba.org/show_bug.cgi?id=1442
https://bugzilla.samba.org/show_bug.cgi?i
https://bugzilla.samba.org/show_bug.cgi?id=11338
--- Comment #3 from Ralph Corderoy ---
Hi Wayne,
I don't know if James's SEGV is the same root cause as Balveer's that
was two years earlier, but I'm seeing SEGV like James's. Both times, my
network connection was down when rsync was run by cron;
https://bugzilla.samba.org/show_bug.cgi?id=13207
Bug ID: 13207
Summary: rsyncd doesn't send output of failed pre-xfer exec
script to client
Product: rsync
Version: 3.1.1
Hardware: x64
OS: Linux
S
https://bugzilla.samba.org/show_bug.cgi?id=7249
--- Comment #8 from Michal Ruprich ---
Is there any update on this feature? Is there a plan to merge the patch into
master branch of rsync?
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for m
https://bugzilla.samba.org/show_bug.cgi?id=13222
Bug ID: 13222
Summary: rsync creates warning if time of destination file
differs in fractional part of second and owner
mismatches
Product: rsync
Version: 3.1.2
https://bugzilla.samba.org/show_bug.cgi?id=13222
--- Comment #1 from Urban Mueller ---
in the short description, I meant to say "chmod" not "chown", sorry.
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omitting th
https://bugzilla.samba.org/show_bug.cgi?id=13224
Bug ID: 13224
Summary: New file handling causes compile issues for NonStop
port.
Product: rsync
Version: 3.1.3
Hardware: Other
OS: Other
Status: N
https://bugzilla.samba.org/show_bug.cgi?id=13222
Wayne Davison changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugzilla.samba.org/show_bug.cgi?id=13224
Randall S. Becker changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
https://bugzilla.samba.org/show_bug.cgi?id=13222
--- Comment #3 from Urban Mueller ---
Thanks for the fix, that will solve my problem. However I think the planned -c
behaviour is surprising in a bad way. If rsync has a way to achieve its desired
target state, IMHO it should. Example: If the targe
https://bugzilla.samba.org/show_bug.cgi?id=13239
Bug ID: 13239
Summary: "rsync --times" does not keep dirs' setgid bits when
user not member of setgid group
Product: rsync
Version: 3.1.2
Hardware: All
OS: Li
https://bugzilla.samba.org/show_bug.cgi?id=13241
Bug ID: 13241
Summary: A problem with test for xattrs transfer
Product: rsync
Version: 3.1.2
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
https://bugzilla.samba.org/show_bug.cgi?id=10332
--- Comment #4 from George ---
Had a similar issue with rsync 3.1.0 on the server, building 3.1.1 with
internal lib solved the problem; therefore -- could indeed be a dup of bug
10372.
--
You are receiving this mail because:
You are the QA Contac
https://bugzilla.samba.org/show_bug.cgi?id=11215
--- Comment #2 from George ---
Anyone experiencing a similar issue may want to have a look at bug 10372 .
( Possibly related: bug 10332. )
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for m
https://bugzilla.samba.org/show_bug.cgi?id=13248
Bug ID: 13248
Summary: Updates for DEFAULT_DONT_COMPRESS suffix list
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
Severity: enhancement
https://bugzilla.samba.org/show_bug.cgi?id=6422
--- Comment #3 from Florian Weimer ---
I posted a patch:
https://lists.samba.org/archive/rsync/2018-February/031476.html
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoi
https://bugzilla.samba.org/show_bug.cgi?id=13266
--- Comment #2 from Daniel Shepherd ---
Created attachment 13955
--> https://bugzilla.samba.org/attachment.cgi?id=13955&action=edit
iMac Pro with "AP" drive.
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Pleas
https://bugzilla.samba.org/show_bug.cgi?id=13266
Bug ID: 13266
Summary: Writing of files to Apple's new "AP" controller model
SSD's takes 4x longer.
Product: rsync
Version: 3.1.3
Hardware: x64
OS: Mac OS X
https://bugzilla.samba.org/show_bug.cgi?id=13266
--- Comment #1 from Daniel Shepherd ---
Created attachment 13954
--> https://bugzilla.samba.org/attachment.cgi?id=13954&action=edit
Early 2017 MacBook Pro (mine) with "SM" model drive.
--
You are receiving this mail because:
You are the QA Cont
https://bugzilla.samba.org/show_bug.cgi?id=13083
Ben RUBSON changed:
What|Removed |Added
Attachment #13681|0 |1
is obsolete|
https://bugzilla.samba.org/show_bug.cgi?id=12522
Ben RUBSON changed:
What|Removed |Added
Attachment #12841|0 |1
is obsolete|
https://bugzilla.samba.org/show_bug.cgi?id=13268
Bug ID: 13268
Summary: [WARN] shifting a negative signed value is undefined
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
Severity: normal
https://bugzilla.samba.org/show_bug.cgi?id=13071
--- Comment #1 from Ben RUBSON ---
Tested and still correctly works with rsync 3.1.3.
Thx !
--
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.
https://bugzilla.samba.org/show_bug.cgi?id=12498
Ben RUBSON changed:
What|Removed |Added
Version|3.1.2 |3.1.3
--- Comment #2 from Ben RUBSON ---
Thi
https://bugzilla.samba.org/show_bug.cgi?id=13266
--- Comment #3 from Daniel Shepherd ---
Have tested this with a 2016 MacBook that also has the "AP" SSD controller and
can confirm the same performance issue.
So it's not just new machines, it's any Mac with an "AP" SSD formatted with
APFS.
--
Y
https://bugzilla.samba.org/show_bug.cgi?id=13266
--- Comment #4 from Chris Tipper ---
Model: iMac 4K (2015)
Platform: macOS 10.13.3
Storage: APFS running on APPLE SSD SM0512G
Symptom: 5% throughput over Gigabit LAN compared to rsync 3.1.2 (4Mb/s vs
100Mb/s)
The target machine is FreeBSD 11.1 ru
https://bugzilla.samba.org/show_bug.cgi?id=13241
Dave Gordon changed:
What|Removed |Added
CC||dg32...@zoho.eu
--- Comment #1 from Dave Gor
https://bugzilla.samba.org/show_bug.cgi?id=10357
Dave Gordon changed:
What|Removed |Added
CC||dg32...@zoho.eu
--- Comment #12 from Dave Go
https://bugzilla.samba.org/show_bug.cgi?id=12820
--- Comment #1 from Dave Gordon ---
(In reply to Pavel Alexeev from comment #0)
The listing at the end of your report is presumably on the sending side; on the
receiver, you should see that the transfer has converted the symlink into a
plain file,
https://bugzilla.samba.org/show_bug.cgi?id=13241
--- Comment #2 from Michal Ruprich ---
Thanks for the answer Dave, I filed this bug a few days before the 3.1.3
version came out. I was trying the make check with 3.1.2 release and there it
was failing. With the new version this test passes without
https://bugzilla.samba.org/show_bug.cgi?id=7249
--- Comment #9 from Michal Ruprich ---
Did any of you who uses rsync with noatime patch had problems with running
'make check' command? It seems to me that some of the source files might be
compiling in different order than with a simple make since
https://bugzilla.samba.org/show_bug.cgi?id=13317
Bug ID: 13317
Summary: rsync returns success when target filesystem is full
Product: rsync
Version: 3.1.2
Hardware: x64
OS: FreeBSD
Status: NEW
Severity: ma
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #1 from Kevin Korb ---
Are you saying that it is exiting with an exit code of 0 after outputting that
error or that sometimes in the same condition it shows no error and exits code
0? Either way it would probably be helpful to see an o
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #2 from Rui DeSousa ---
(In reply to Kevin Korb from comment #1)
I saying that in some cases the rename does not fail; and in those cases it
returns success despite there not being enough space to store the original
file. It looks lik
https://bugzilla.samba.org/show_bug.cgi?id=13320
Bug ID: 13320
Summary: file contents cause rsync to fail (with certains args
and dir structure)
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
https://bugzilla.samba.org/show_bug.cgi?id=13320
--- Comment #1 from Dave Gordon ---
Bug will be triggered if:
options include both --sparse and --preallocate, AND
the second (or subsequent) file to be copied begins with one or more zero
bytes.
.Dave.
--
You are receiving this mail because:
Y
https://bugzilla.samba.org/show_bug.cgi?id=13320
--- Comment #2 from Dave Gordon ---
Created attachment 14018
--> https://bugzilla.samba.org/attachment.cgi?id=14018&action=edit
Simple although probably suboptimal fix
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.samba.org/show_bug.cgi?id=13320
--- Comment #3 from Dave Gordon ---
Problem introduced by
commit f3873b3d88b61167b106e7b9227a20147f8f6197
Author: Wayne Davison
Date: Mon Oct 10 11:49:50 2016 -0700
Support --sparse combined with --preallocate or --inplace.
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #3 from Dave Gordon ---
(In reply to Rui DeSousa from comment #2)
Here's a snippet from Oracle's ZFS help ...
https://docs.oracle.com/cd/E19253-01/819-5461/gitfx/index.html
"Enforcement of user and group quotas might be delayed by sev
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #4 from Dave Gordon ---
To see whether rsync is getting any errors reported by any system calls it
makes, one could run it under strace(1) on Linux, or dtrace on Solaris.
Presumably FreeBSD has at least one of these, or something simila
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #5 from Rui DeSousa ---
(In reply to Dave Gordon from comment #4)
Hi Dave,
I'm not seeing any errors on the write calls. Would an fsync() be required to
force the error?
[postgres@hades ~]$ grep ERR rsync.test.log
52419: lstat("/usr
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #6 from Rui DeSousa ---
(In reply to Rui DeSousa from comment #5)
It looks like no error is returned and result is a sparse file. I think a
sync() would be required otherwise the file is truncated on close to meet the
quota.
[postgr
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #7 from Dave Gordon ---
(In reply to Rui DeSousa from comment #5)
That was a run where the rename failed. Do you know whether the temporary file
was truncated or corrupted in that scenario?
[HINT: one can stop the rsync with a signal,
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #8 from Ben RUBSON ---
(In reply to Dave Gordon from comment #3)
> ZFS probably notices the quota problem somewhere between (b) and (c), drops
> the excess data, and returns EDQUOT to the close(2) call.
(In reply to Dave Gordon from c
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #9 from Dave Gordon ---
(In reply to Rui DeSousa from comment #6)
In your example:
$ rsync -av --inplace 0001005E0017 arch/0001005E0017
sending incremental file list
0001005E0017
sent 67,125,370 byt
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #10 from Dave Gordon ---
BTW, have you tried *either* --sparse *or* --preallocate (but not both
together, please, as that will trigger bug 13320 -
https://bugzilla.samba.org/show_bug.cgi?id=13320)
Does you get the same problem (i.e. fi
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #11 from Rui DeSousa ---
(In reply to Dave Gordon from comment #7)
This is the result of hard link on the temp file where the rename failed.
root@hades:~postgres/arch # ls -lh rsync.temp ; du -h rsync.temp
-rw--- 1 postgres pos
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #12 from Rui DeSousa ---
(In reply to Dave Gordon from comment #10)
The sparse option errors out :).
[postgres@hades ~]$ rsync -av --sparse 0001005E0017
arch/0001005E0017
sending incremental file list
0001
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #13 from Rui DeSousa ---
(In reply to Rui DeSousa from comment #12)
Running truss on the --sparse option does show the error being is returned
during the write call.
[postgres@hades ~]$ truss -f -o sparse.log rsync -av --sparse
0
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #14 from Dave Gordon ---
(In reply to Rui DeSousa from comment #6)
So you now have an example which reliably produces a bad outcome (corrupted
file)? With the combination of
(a) insufficient space before copying, and
(b) --inplace so t
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #15 from Ben RUBSON ---
Rui just to be sure, which type of ZFS quota are you using ?
quota ? refquota ? userquota ?
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #16 from Rui DeSousa ---
(In reply to Ben RUBSON from comment #15)
I just set the quota property.
NAME PROPERTY VALUE SOURCE
hydra/home/postgres/arch quota 1Glocal
hydra/home/postgres/a
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #17 from Rui DeSousa ---
(In reply to Dave Gordon from comment #14)
Here's the output you requested. ZFS would use the same block even if it's the
same data as don't have dedup enabled.
[postgres@hades ~]$ ls arch/
dbc1
[postgres@had
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #18 from Rui DeSousa ---
I also wrote a little util as well; I get the correct error in write spot.
[postgres@hades ~]$ cat 0001005E0017 | ./fwrite/fwrite
arch/0001005E0017
fwrite: write: Disc quota exceeded
[po
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #19 from Ben RUBSON ---
I managed to reproduce the issue on 11.0-RELEASE-p16.
Below a simple test case, without compression, without deduplication.
Note that issue is reproductible with quota, but not with userquota.
# f=/test
# z=zroo
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #20 from Dave Gordon ---
So, looking like a ZFS issue but triggered in some way by the specific
behaviour of rsync (e.g. writing a certain block size/pattern causes the quota
error to be lost). The truss listing from a failing case shou
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #21 from Dave Gordon ---
Created attachment 14019
--> https://bugzilla.samba.org/attachment.cgi?id=14019&action=edit
Test patch to see whether fdatasync() or fsync() detects a write failure
--
You are receiving this mail because:
Yo
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #22 from Dave Gordon ---
(In reply to Ben RUBSON from comment #19)
Just to be totally certain about what ZFS may or may not share between files,
could you try this variant of your testcase:
# zfs destroy $z
# zfs create $z
# zfs set c
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #23 from Dave Gordon ---
Looks like this ZFS problem could be a FreeBSD-specific issue; one of the
commits mentioned in this FreeNAS bug report has the subject
zfs_write: fix problem with writes appearing to succeed when over quota
S
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #24 from Ben RUBSON ---
ZFS only shares between files with dedup on.
So first rsync / diff succeeded, second gave same result as before :
# rsync -a --inplace $tmpfs/f1 $f/f3 ; echo $? ; diff $tmpfs/f1 $f/f3
0
Files /mnt/f1 and /test/f3
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #25 from Ben RUBSON ---
And here is the patch applied to FreeBSD stable/10 :
https://reviews.freebsd.org/rS326428
And to FreeBSD stable/11 :
https://reviews.freebsd.org/rS326427
Will then be in FreeBSD 11.3.
Note that this patch depen
https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #26 from Rui DeSousa ---
(In reply to Ben RUBSON from comment #25)
That is awesome. Thanks you for all of your efforts!
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most r
https://bugzilla.samba.org/show_bug.cgi?id=13321
Bug ID: 13321
Summary: Rsync --copy-dest issue
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P5
101 - 200 of 690 matches
Mail list logo
