Issues with error reporting vs error exiting about ltopers HOT 7 CLOSED

I suspect that migratefiles isn't returning an error code, when it fails. I suggest that it should pass along the error code of the copying utility that it is using.

from ltopers.

It looks like migratefiles also will pass on an error code 1 due to it also using _run_critical_event, so it isn't directly passing on the rsync error code, but is passing its own? https://github.com/mediamicroservices/mm/blob/master/migratefiles#L47

Also, sorry for the maybe obvious question - but with the files being copied to tape in the first pass by gcp, what are the two passes of rsync via migratefiles trying to copy over?

from ltopers.

for reference, here is the thread of errors - rsync error 23-> migratefiles error 1-> writelto abort

rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1209) [sender=3.1.3]
2018-03-08T03:26:56 - [migratefiles]Error: Running: "rsync -rtvPih --log-file=/Users/mac1/migrate.log --log-file-format=20180308-032616 '%f' %l '/Volumes/B00001/' /Volumes/HD2/LTO_DONE/ /Volumes/B00001/" gave an Error Code - 23
2018-03-08T03:26:56 - [migratefiles]The process ran into a critical error and can not proceed.
2018-03-08T03:26:56 - [writelto]Error: Running: "/usr/local/bin/migratefiles -o /Volumes/B00001 /Volumes/HD2/LTO_DONE/" gave an Error Code - 1
2018-03-08T03:26:56 - [writelto]The process ran into a critical error and can not proceed.
mac1:~ mac1$

from ltopers.

It looks like this is a bug introduced in d63047f with the integration of DB reporting via mm by ahem me. I propose we switch back to the original way of calling migratefiles

from ltopers.

@privatezero Can this one be closed?

from ltopers.

yup yup! Should be resolved in #171

from ltopers.

Thank you!

from ltopers.