Seemingly impossible bug: -v not always listing every copied file

Joe josephj at main.nc.us
Wed Oct 30 16:45:57 UTC 2019


If you are doing a small test run that duplicates the problem, you could
use inotifywait or tail -f to watch the log in real time on another
terminal. Maybe you'd see something like a line being overwritten, etc.

I don't know what rsync would do with a file name that ends in a
carriage return (not a newline). It's probably smart enough to handle
it, but if it isn't, the current log line might be overwritten by the
next one.

Joe

On 10/30/19 1:24 AM, raf via rsync wrote:
> Thanks. I'll try that. But I agree that it'll be
> something else. It's unlikely that whole trace files
> are being overwritten, because there's locking in place
> to prevent that sort of thing, but it's more likely
> than anything else. I'll check that the locking is
> working properly.
>
> Although, when I last investigated it, it really did
> look as though, in a single run of this task, three
> files were copied for one directory but only two were
> listed. I need to verify that more thoroughly, perhaps
> with directory listings on both sides before and after
> each run.
>
> cheers,
> raf
>
> Kevin Korb via rsync wrote:
>
>> It does seem impossible.  I would suggest adding --itemize-changes (-v
>> isn't really all that useful without it anyway).  If entries are still
>> missing then I would suspect that either log files are missing (maybe
>> duplicate file names replacing the occasional log file?) or something
>> other than rsync is doing things in the same dir.
>>
>> On 10/29/19 9:00 PM, raf via rsync wrote:
>>> Hi,
>>>
>>> debian-9, rsync-3.1.2 (both ends)
>>>
>>> I have a task that rsyncs files from a list of
>>> candidate files (--files-from=). It's verbose (-v) and
>>> its stdout is captured to a file which is then sent to
>>> the receiving host. The captured verbose output is
>>> examined on the receiving host to know which files were
>>> actually copied so that notification emails can be sent
>>> to various people.
>>>
>>> The problem is that, sometimes, not all copied files
>>> are listed in the verbose output, and so some
>>> notification emails don't get sent out. At first, I
>>> thought there was something wrong with the notification
>>> emails not arriving, but the files in question, that
>>> had definitely been copied, did not appear in any of
>>> the captured verbose output files.
>>>
>>> This seems like an impossible bug but it really seems
>>> to be happening. Has anyone else encountered behaviour
>>> like this? I didn't have much luck searching the
>>> internet for it. It would probably be hard to notice
>>> if the verbose output wasn't being used for something
>>> like triggering notifications whose absence might be
>>> noticed.
>>>
>>> cheers,
>>> raf
>> -- 
>> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
>> 	Kevin Korb			Phone:    (407) 252-6853
>> 	Systems Administrator		Internet:
>> 	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
>> 	Orlando, Florida		kmk at sanitarium.net (personal)
>> 	Web page:			https://sanitarium.net/
>> 	PGP public key available on web site.
>> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
>>
>
>
>
>> -- 
>> Please use reply-all for most replies to avoid omitting the mailing list.
>> To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
>> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
>



More information about the rsync mailing list