[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #28 from Dave Gordon --- (In reply to Carson Gaspar from comment #27) Hmm? If you're referring to line 810 of io.c, which is the only write(2) call I can see in perform_io(), in the current HEAD it looks like this:

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #27 from Carson Gaspar --- (In reply to Dave Gordon from comment #23) Reading this, I took a look at the rsync sources, and, indeed, rsync has a bug. perform_io() does not correctly check the return code from

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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=edit Test patch to see whether fdatasync() or fsync() detects a write failure -- You are receiving this mail

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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:

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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 1G

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

is 64M, but which is compressed to 19M on disk. ZFS uncompresses it on the fly and delivers 64M of data to the first rsync. rsync sequentially writes 64M, checking the success of each write. The last write should end at an offset of 64M, then the destination file is closed (and the return from that is c

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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

Re: [Bug 13317] rsync returns success when target filesystem is full

On Mon, Mar 5, 2018 at 3:09 PM, just subscribed for rsync-qa from bugzilla via rsync wrote: > 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

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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

[Bug 13317] rsync returns success when target filesystem is full

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,

[Bug 13317] rsync returns success when target filesystem is full

eturns EDQUOT to the close(2) call. The success of the rename depends only on whether there is sufficient free space at that instant; any previous failure in writing the file won't affect the rename directly. Rename may not always need any extra space anyway. BTW: apropos your comment a

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #2 from Rui DeSousa <rui.deso...@icloud.com> --- (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

[Bug 13317] rsync returns success when target filesystem is full

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

Re: files not moved immediately to final destination from temp location after rsync returns with success

Yes, we are not trying to directly access the data via calls outside the file system so the VFS should have handled it correctly. Our logs don't show any type of errors related to SD card access or file system access in general. Thanks, Alistair On Sat, Apr 23, 2011 at 9:04 AM, Cameron Simpson

Re: files not moved immediately to final destination from temp location after rsync returns with success

or file system errors in general. Regards, Alistair On Sat, Apr 23, 2011 at 9:06 PM, Wayne Davison way...@samba.org wrote: On Wed, Apr 20, 2011 at 12:44 PM, Alistair Dsouza alista...@gmail.comwrote: I came across an issue where it seems that the rsync call returned with a success

Re: files not moved immediately to final destination from temp location after rsync returns with success

mailto:way...@samba.org wrote: On Wed, Apr 20, 2011 at 12:44 PM, Alistair Dsouza alista...@gmail.com mailto:alista...@gmail.com wrote: I came across an issue where it seems that the rsync call returned with a success but the files that it pulled are not moved immediately

Re: files not moved immediately to final destination from temp location after rsync returns with success

On Wed, Apr 20, 2011 at 12:44 PM, Alistair Dsouza alista...@gmail.comwrote: I came across an issue where it seems that the rsync call returned with a success but the files that it pulled are not moved immediately to its final destination. I think it more likely that you had 2 instances

Re: files not moved immediately to final destination from temp location after rsync returns with success

On 20Apr2011 19:29, Tony Abernethy t...@servasoftware.com wrote: | OK, I'll bite. | With all file system designs, there is a tradeoff between speed and safety. | This tradeoff occurs at all levels where there might be something that buffers information. | Writing into the middle of a structure

Re: files not moved immediately to final destination from temp location after rsync returns with success

call returned with a success but the files that it pulled are not moved immediately to its final destination. You could try issuing the 'sync' command? However, I do not think believe that this should be required. Perhaps someone else on this list will have some other ideas

RE: files not moved immediately to final destination from temp location after rsync returns with success

-boun...@lists.samba.org] On Behalf Of Henri Shustak Sent: Wednesday, April 20, 2011 6:17 PM To: rsync Subject: Re: files not moved immediately to final destination from temp location after rsync returns with success I am using rsync version 3.0.7 on an arm linux based embedded device

Re: rsync email notification on success and failure + Log

I have a bash script for rsync that should tranfer all my filer from one drive to the other. I would like to know how I can make the script sending me an email after the script is run and be able to know if it was a success or not and also if possible to include the log file. You may

Re: rsync email notification on success and failure + Log

my filer from one drive to the other. I would like to know how I can make the script sending me an email after the script is run and be able to know if it was a success or not and also if possible to include the log file. This is my script: !/bin/bash rsync -av --delete --log-file=/home

rsync email notification on success and failure + Log

Hi, I have a bash script for rsync that should tranfer all my filer from one drive to the other. I would like to know how I can make the script sending me an email after the script is run and be able to know if it was a success or not and also if possible to include the log file

Re: rsync email notification on success and failure + Log

Hi, On Wed, 30 Dec 2009, Sébastien Arpin wrote: I have a bash script for rsync that should tranfer all my filer from one drive to the other. I would like to know how I can make the script sending me an email after the script is run and be able to know if it was a success or not and also

3.0.1 Test Success MacOS X 10.4.11

I have also been eager to test bbouncer The latest source passes with flying colours! but make check finds some problems with xattrs if not run by sudo I have xattr in /usr/local/bin/ from the source found at: http://dev.bignerdranch.com/public/bnr/eXttra.zip What I did: cd /usr/local/Source

The Number One Success System Gifting

http://www.noss123.com/ is a party who acts as an intermediary between sellers and buyers of real estate and attempts to find sellers who wish to sell and buyers who wish to buy. In the United States, the relationship was originally established by reference to the English common law of agency

RE: More confusion on exclude rules (Success)

Found a space after + /nflmg/scripts/regional/misc_loaders/ which caused the subdirectory to be missed. Thanks a bunch for your example. That illustrated the issue well. Once I got rid of the space and saw that your example did work, it made it much easier to understand how the rules build. The

Re: Getting nowhere syncing a download SUCCESS

On Fri, 7 Mar 2003 04:32, Max Bowsher wrote: bob parker wrote: On Fri, 7 Mar 2003 04:10, Max Bowsher wrote: bob parker wrote: On Fri, 7 Mar 2003 03:47, Max Bowsher wrote: Curious. I wonder why rsync thinks the file is up to date. Maybe the -I or -c options would make it look more

success

after following my earlier about rsync and inetd not binding properly, i have rsync working! many thanks to the suggestions brought forward on this mailing list. hope holidays are happy! Robb Benedict All Things Computers -- To unsubscribe or change options:

Bogus rsync Success message when out of disk space

To the rsync maintainers: When rsync 2.5.5 is pulling files and the target disk runs out of space, this is what the tail end of the message stream looks like (w/--verbose): write failed on games/ghostmaster/ectsdemo2002.zip : Success rsync error: error in file IO (code 11) at receiver.c(243