https://bugzilla.samba.org/show_bug.cgi?id=13953
Bug ID: 13953
Summary: error message instead of --stats informations (in case
of vanished files), using rsync 3.1.1 and rsync 3.0.9
Product: rsync
Version: 3.1.1
Hardware
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
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 #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@
on osx locally,
i.e. if i rsync -av /tmp/localdir/rapidly-appearing+disappearing-files-inside
/tmp/localdir2 on osx locally, i`m getting all vanished files messages
including which files are missing on stdout.
if i do the same from linux/remote, then the information which files are
vanished goes
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
mes and decide if it is a problem or not.
>
> On 09/07/2017 10:27 AM, Vangelis Katsikaros via rsync wrote:
>> Hi
>>
>> I would like to ask, when the "vanished files" warning is a sign that
>> something bad is happening somewhere. I know that the `rsync-no-
All it means is that rsync saw a file that needed transferring but the
file was gone when rsync actually tried to open it. So look at the
filenames and decide if it is a problem or not.
On 09/07/2017 10:27 AM, Vangelis Katsikaros via rsync wrote:
> Hi
>
> I would like to ask, when the
Hi
I would like to ask, when the "vanished files" warning is a sign that something
bad is happening somewhere. I know that the `rsync-no-vanished` script can
silence the warning, but I am wondering whether this is a sane thing to do.
My guess based on https://bugzilla.samba.org/show_
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #27 from samba ---
Still an issue on rsync-3.1.1-3 as found on Debian 8
--
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 unsub
https://bugzilla.samba.org/show_bug.cgi?id=10601
--- Comment #1 from Haravikk 2014-05-09 19:25:27 UTC ---
Just wanted to add that it may make sense to separate the retry somehow so that
folders can be retried while files are skipped, for example, as backups of an
in-use hierarchy will be more lik
https://bugzilla.samba.org/show_bug.cgi?id=10601
Summary: Retry Delay for Vanished Files/Directories
Product: rsync
Version: 3.1.0
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
https://bugzilla.samba.org/show_bug.cgi?id=3653
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #25 from jakob...@gmail.com 2014-01-01 15:04:58 UTC ---
What remains to be done is to make the the rsync-no-vanished script accessible
to users. I created bug 10356 about including it in the tarball.
--
Configure bugmail: https://bugzil
https://bugzilla.samba.org/show_bug.cgi?id=3653
Nick Hibma changed:
What|Removed |Added
CC||n...@anywi.com
--- Comment #24 from Nick Hibma
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #23 from g...@delfi.ee 2011-02-11 09:41 CST ---
i updated patch again as found similar pattern in code
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/rsync/ignore-vanished.patch?rev=1.2
but seems the problem is report
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #22 from g...@delfi.ee 2011-01-25 13:55 CST ---
Created an attachment (id=6228)
--> (https://bugzilla.samba.org/attachment.cgi?id=6228&action=view)
updated patch in #c1 against rsync-3.0.7
--
Configure bugmail: https://bu
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #21 from m...@mattmccutchen.net 2010-11-21 21:12 CST ---
(In reply to comment #20)
> AFAICS, delete_in_dir() suppresses deletion when /any/ flag is set in
> io_error:
>
> if (io_error && !ignore_errors) {
Indeed, t
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #20 from jr-sambabugzi...@quo.to 2010-11-21 19:43 CST ---
(In reply to comment #19)
> You're right that the IOERR_GENERAL flag (which corresponds to that message)
> stops all destination files from being deleted. But it is o
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #19 from m...@mattmccutchen.net 2010-11-21 17:57 CST ---
(In reply to comment #18)
> What's also annoying is that a "vanished file" warning triggers:
>
> "IO error encountered -- skipping file deletion"
>
> which if I'm not
https://bugzilla.samba.org/show_bug.cgi?id=3653
jr-sambabugzi...@quo.to changed:
What|Removed |Added
CC||jr-sambabugzi...@quo.to
--
ackup : http://www.lbackup.org
Just one rsync based backup possibility.
Note : The current version 0.9.8r5-alpha3 of LBackup, requires a wrapper script
to be
put around rsync if you want to ignore the vanished files warning. :
http://www.lbackup.org/developer/ignore_vanished_file_warnings
A
https://bugzilla.samba.org/show_bug.cgi?id=3653
j...@jwz.org changed:
What|Removed |Added
CC||j...@jwz.org
--- Comment #17 from j..
the case but I would mention it
> anyway).
> My immediate problem is that rsync proceeds happily and deletes any
> vanished files in the end (--delete-after).
> rsync stops with exit code 24, but by then the damage is already done
> (files deleted) .
On Fri, 2009-10-23 at 1
nk that this is the case but I would mention
>it anyway).
>My immediate problem is that rsync proceeds happily and deletes any
>vanished files in the end (--delete-after).
>rsync stops with exit code 24, but by then the damage is already done
>(files deleted) .
Strange, I have c
the case but I would mention
>it anyway).
>My immediate problem is that rsync proceeds happily and deletes any
>vanished files in the end (--delete-after).
>rsync stops with exit code 24, but by then the damage is already done
>(files deleted) .
Strange, I have code 23 whe
se but I would mention
it anyway).
My immediate problem is that rsync proceeds happily and deletes any
vanished files in the end (--delete-after).
rsync stops with exit code 24, but by then the damage is already done
(files deleted) .
The question is: Is there a way to avoid the deletio
ppily and deletes any
vanished files in the end (--delete-after).
rsync stops with exit code 24, but by then the damage is already done
(files deleted) .
The question is: Is there a way to avoid the deletion when vanished
files are detected? That would be "no deletion at all" or just &
from r...@golder.org 2009-05-18 07:59 CST ---
This is a 'me too' for '--ignore-vanished-files' flag. Lots of legitimate cases
where files could vanish, so having the option to treat this as normal (i.e.
prevent rsync from producing this warning and ensure a zero exit val
/snapback2 2>&1`
RET=$?
if [ "$RET" != "23" -a "$RET" != "0" -a "$RET" != 24 ]; then
echo "$OUT"
exit $RET
fi
this is a workaround, it would still be great to be able to tell rsync to
ignore vanished files.
--
Co
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #14 from rv-rsyncbugzi...@eychenne.org 2009-04-22 03:39 CST
---
I also find this warning annoying, I really vote for this patch.
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--- You are rec
https://bugzilla.samba.org/show_bug.cgi?id=3653
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment #1
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #12 from [EMAIL PROTECTED] 2008-06-04 20:24 CST ---
Created an attachment (id=3335)
--> (https://bugzilla.samba.org/attachment.cgi?id=3335&action=view)
Demonstration of two nasty vanishing cases
Even with the changes I prop
On Thu, 2008-03-06 at 11:56 -0500, Justin Pryzby wrote:
> On Mon, Feb 20, 2006 at 02:28:50PM +0300, Cyril Bouthors wrote:
> > I'd like rsync to provide an option called '--ignore-vanished' that
> > would not display those warnings anymore and not exit with value 24
> > ("Partial transfer due to van
, Cyril Bouthors wrote:
>> Package: rsync
>> Version: 2.6.6-1
>> Severity: wishlist
>>
>> I make nightly backups of 1TB+ of data that are continuously
>> read-write accessed and I constantly have *huge* output of the cron
>> job because of vanished files:
d and I constantly have *huge* output of the cron
> job because of vanished files:
>
> file has vanished: "/drbd/var/www/tmp/sess_003323885e425f2a67e69e0ac4c24124"
> file has vanished: "/drbd/var/www/tmp/sess_033cc2efa0b325a2d154c082995d
On Mon, 2007-12-24 at 01:27 -0500, Matt McCutchen wrote:
> On Sun, 2007-12-23 at 15:55 -0500, Ming Zhang wrote:
> > if sender read by path again and get ENOENT, then this ENOENT can tell
> > rsync enough info. (though current rsync might say partial transfer
> > though it is a vanished file... )
>
On Sun, 2007-12-23 at 15:55 -0500, Ming Zhang wrote:
> if sender read by path again and get ENOENT, then this ENOENT can tell
> rsync enough info. (though current rsync might say partial transfer
> though it is a vanished file... )
Treating the file as completely vanished on the basis of the ENOEN
On Thu, 2007-12-20 at 10:24 -0500, Matt McCutchen wrote:
> On Wed, 2007-12-19 at 22:25 -0500, Ming Zhang wrote:
> > so this file-list is the internal file list, not the --files-from
> > content.
>
> Yes, the correctness property is based on the internal file list.
>
> > rsync's goal is to keep sr
On Wed, 2007-12-19 at 22:25 -0500, Ming Zhang wrote:
> so this file-list is the internal file list, not the --files-from
> content.
Yes, the correctness property is based on the internal file list.
> rsync's goal is to keep src and dest in same state (same content, or the
> fact that none side ha
On Wed, 2007-12-19 at 21:22 -0500, Matt McCutchen wrote:
> On Sun, 2007-12-16 at 13:47 -0500, Ming Zhang wrote:
> > > even code 24 is in order because the nonexistence of a --files-from
> > > entry cannot affect the correctness of a run with --delete in the way
> > > that a traditional vanishing ca
On Sun, 2007-12-16 at 13:47 -0500, Ming Zhang wrote:
> > even code 24 is in order because the nonexistence of a --files-from
> > entry cannot affect the correctness of a run with --delete in the way
> > that a traditional vanishing can.
>
> not quite understand what u meant here...
Sorry. I was
On Fri, 2007-12-14 at 23:27 -0500, Matt McCutchen wrote:
> On Fri, 2007-12-14 at 18:24 -0500, Ming Zhang wrote:
> > What should be the right exit code for vanished file in this scenario.
> >
> > (1) Use inotify or other mechanism to check changed files and then
> > generate a file list.
> >
> > (
On Fri, 2007-12-14 at 18:24 -0500, Ming Zhang wrote:
> What should be the right exit code for vanished file in this scenario.
>
> (1) Use inotify or other mechanism to check changed files and then
> generate a file list.
>
> (2) < file get deleted>
>
> (3) run rsync with --files-from with the ol
Hi
What should be the right exit code for vanished file in this scenario.
(1) Use inotify or other mechanism to check changed files and then
generate a file list.
(2) < file get deleted>
(3) run rsync with --files-from with the old list.
then send_file_list()->link_stat() will return errno 2 o
Matt McCutchen wrote:
>
> If a file has vanished and there is also an error that affects the
> correctness of the transfer, the code 23 takes precedence over the code
> 24. Check rsync's output for any error messages. If there are none,
>
Indeed that is the case. I did not realize at first
For partial transfers due to vanished files, I (and my script) would
> expect exit code 24.
If a file has vanished and there is also an error that affects the
correctness of the transfer, the code 23 takes precedence over the code
24. Check rsync's output for any error messages. If th
I am using rsync 2.6.9 (as currently packaged in Mandriva 2007.1)
Ever since the latest update of the package I have been getting an exit
code of 23 with the output "file has vanished: {filename}".
For partial transfers due to vanished files, I (and my script) would
expect exit code
On 8/23/07, Samuel Vogel <[EMAIL PROTECTED]> wrote:
> I've been trying to transfer about 90GB from one Server to another using
> rsync. But rsync stops randomly. I use the bash script provided in a bug
> report, to block errors about vanished files!
I wonder if this is t
I installed the CVS version on both sides!
Fabian Cenedese schrieb:
At 16:43 24.08.2007 +0200, Samuel Vogel wrote:
I installed the latest CVS Version (today about 1pm). Again, the same problem
occured...
Did you have it on both sides? Did rsync say "sending incremental
file list" (pr
At 16:43 24.08.2007 +0200, Samuel Vogel wrote:
>I installed the latest CVS Version (today about 1pm). Again, the same problem
>occured...
Did you have it on both sides? Did rsync say "sending incremental
file list" (probably only with -v)? It only does so if the rsync on the other
side understand
I installed the latest CVS Version (today about 1pm). Again, the same
problem occured...
Andre Majorel schrieb:
On 2007-08-24 12:02 +0200, Samuel Vogel wrote:
Andre Majorel schrieb:
If you have directories with many files, rsync becomes a memory
hog. I've had it bring down a 1-GB mac
On 2007-08-24 12:02 +0200, Samuel Vogel wrote:
> Andre Majorel schrieb:
>
> >If you have directories with many files, rsync becomes a memory
> >hog. I've had it bring down a 1-GB machine while copying a 10-GB
> >news spool.
>
> Thanks for the reply. Do you mean on the rsync server or client
> side?
Thanks for the reply. Do you mean on the rsync server or client side?
The client has 4GB of Ram, the server only has 1GB. I try to download
from the server to the client.
I'm sure that there is no file bigger than 500MB. And there can't be any
files 1GB, because we have 1GB quotas in place!
Li
At 06:58 24.08.2007 +0200, Samuel Vogel wrote:
>I don't think this is possible. Pretty much no services except ssh are running
>on the machine that I'm running the rsync client on. The partition I'm
>transferring the files to hast 400GB of space left and 3.7 GB of my 4GB memory
>are still free..
I don't think this is possible. Pretty much no services except ssh are
running on the machine that I'm running the rsync client on. The
partition I'm transferring the files to hast 400GB of space left and 3.7
GB of my 4GB memory are still free...
Any other suggestions?
Do you think it could be
Hey,
I've been trying to transfer about 90GB from one Server to another using
rsync. But rsync stops randomly. I use the bash script provided in a bug
report, to block errors about vanished files!
Here is how I start rsync:
./rsync-no-vanished -v -a -e ssh --delete --progress -z
[
Hi,
On Sat, 11 Aug 2007, Samuel Vogel wrote:
> The vanished files problem is really REALLY annoying... It renders rsync
> unusable for me:
>
> sent 22972933 bytes received 2399590976 bytes 310684.69 bytes/sec
> total size is 98068497125 speedup is 40.48
> client_run
On 8/10/07, Samuel Vogel <[EMAIL PROTECTED]> wrote:
> The vanished files problem is really REALLY annoying... It renders rsync
> unusable for me:
How is rsync unusable? It still does its job, and you can use my bash
script to suppress the warnings and the exit code.
Matt
--
To un
The vanished files problem is really REALLY annoying... It renders rsync
unusable for me:
sent 22972933 bytes received 2399590976 bytes 310684.69 bytes/sec
total size is 98068497125 speedup is 40.48
client_run2 waiting on 18377
_exit_cleanup(code=24, file=main.c, line=1385): entered
rsync
t was last year and the bug report doesn't mention a real
solution except the bash script.
Did anything happen on this? The proposed way to handle vanished files
like they didn't exist is a good solution in my oppinion. Because this
would fix my problem!
Regards,
Samy
--
To unsubs
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #11 from [EMAIL PROTECTED] 2006-10-14 19:01 MST ---
Andreas, you have a point about the special nature of the "file has vanished"
message. The message seems to be an artifact of rsync's implementation that
isn't meaningful a
#10 from [EMAIL PROTECTED] 2006-10-13 03:54 MST ---
I have a theory that vanised files are caused
by clock sync of ntpdate or hwclock.
Please could you check if the vanished files apears only
when a cron job of ntpdate is done ?
Patching rsync to hide vanished files is just a work around
and
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #9 from [EMAIL PROTECTED] 2006-06-14 08:19 MST ---
Well, easy-to-use would be --ignore-vanished ;) .. as rsync is the one emitting
the warning.
"pipefail" is a bash 3.x feature, which hasn't made it into all distributions
(y
https://bugzilla.samba.org/show_bug.cgi?id=3653
[EMAIL PROTECTED] changed:
What|Removed |Added
Attachment #1957|text/sh |text/plain
mime type|
https://bugzilla.samba.org/show_bug.cgi?id=3653
[EMAIL PROTECTED] changed:
What|Removed |Added
Attachment #1957|application/octet-stream|text/sh
mime type|
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #8 from [EMAIL PROTECTED] 2006-06-12 09:02 MST ---
Created an attachment (id=1957)
--> (https://bugzilla.samba.org/attachment.cgi?id=1957&action=view)
fixed rsync-no-vanished wrapper script
You have a point about security u
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #7 from [EMAIL PROTECTED] 2006-06-12 03:55 MST ---
Patching my copy would bar me from Debian (security) updates.
... btw, the script DOES NOT work as expected :(
try:
mkdir a ; mkdir b ; rsync -r a b ; echo $? ; rm -rf a b
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #6 from [EMAIL PROTECTED] 2006-06-09 19:17 MST ---
I still think that incorporating a patch into the official rsync for something
done so easily outside of rsync would be foolish. Of course you are welcome to
patch your own
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #5 from [EMAIL PROTECTED] 2006-06-09 10:28 MST ---
works, thank you. I'd love the patch to be included nonetheless, so I don't
have to spawn yet another shell every time :-/
--
Configure bugmail: https://bugzilla.samba.org
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #4 from [EMAIL PROTECTED] 2006-06-07 17:41 MST ---
(In reply to comment #3)
> when I'm calling rsync from meep (http://freshmeat.net/projects/meep/) I can't
> filter the error messages or change the error code before meep get
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #3 from [EMAIL PROTECTED] 2006-06-07 09:20 MST ---
(In reply to comment #2)
> I think filtering error messages should be the job of the cron script invoking
> rsync, not of rsync itself; otherwise we'll find ourselves adding
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #2 from [EMAIL PROTECTED] 2006-04-03 14:59 MST ---
I think filtering error messages should be the job of the cron script invoking
rsync, not of rsync itself; otherwise we'll find ourselves adding options to
disable each of th
https://bugzilla.samba.org/show_bug.cgi?id=3653
--- Comment #1 from [EMAIL PROTECTED] 2006-04-03 07:13 MST ---
diff -u -r1.332 options.c
--- options.c 28 Mar 2006 23:09:36 - 1.332
+++ options.c 3 Apr 2006 12:12:44 -
@@ -113,6 +113,7 @@
int checksum_seed = 0;
int inp
https://bugzilla.samba.org/show_bug.cgi?id=3653
Summary: Silence 'vanished files' messages
Product: rsync
Version: 2.6.8
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Pr
On Wed, Oct 12, 2005 at 03:59:51PM -0400, Bill Crowell wrote:
> I request an option flag '--ignore-vanished' to be added. This flag
> would disable exit 24.
This is easy to code up using a shell-script wrapper, and one such
wrapper has even been posted to the mailing list before.
..wayne..
--
T
s causes the paranoia messages to go out.
Reading the documentation, I see no method or option to deal with this
situation.
I request an option flag '--ignore-vanished' to be added. This flag would
disable exit 24. With the -v option, vanished files would be described as
"file
o go out.
Reading the documentation, I see no method or option to deal with this
situation.
I request an option flag '--ignore-vanished' to be added. This flag
would disable exit 24. With the -v option, vanished files would be
described as "file xxx Vanished - Ignored" so
78 matches
Mail list logo
