COPS fails to update

[hgy59]

COPS fails to update

[mreid-tt]

I was able to reproduce the problem reported by upgrading from version 1.4.2-7 to version 1.5.4-8. I do apologise that this was a test that I missed in my review. From the install log I see the same sequence:

2023/12/21 21:36:59	===> Step postinst. STATUS=UPGRADE USER=cops GROUP= SHARE_PATH=
2023/12/21 21:36:59	Begin save_wizard_variables
2023/12/21 21:36:59	End save_wizard_variables
2023/12/21 21:36:59	Begin syno_sync_var_folder
2023/12/21 21:36:59	End syno_sync_var_folder
2023/12/21 21:36:59	Begin service_postinst
2023/12/21 21:36:59	End service_postinst
2023/12/21 21:36:59	upgrade cops 1.5.4-8 End postinst ret=[0]
2023/12/21 21:36:59	upgrade cops 1.5.4-8 Begin postupgrade
2023/12/21 21:36:59	Begin initialize_variables
2023/12/21 21:36:59	End initialize_variables
2023/12/21 21:36:59	===> Step postupgrade. STATUS=UPGRADE USER=cops GROUP= SHARE_PATH=
2023/12/21 21:36:59	Begin service_restore
2023/12/21 21:37:00	Restore previous data from /volume1/@tmp/synopkg.tmp/cops/cops
2023/12/21 21:37:00	rsync: change_dir#3 "/var/services/web_packages/cops" failed: No such file or directory (2)
2023/12/21 21:37:00	rsync error: errors selecting input/output files, dirs (code 3) at main.c(729) [Receiver=3.1.2]
2023/12/21 21:37:00	rsync: change_dir#3 "/var/services/web_packages/cops" failed: No such file or directory (2)
2023/12/21 21:37:00	rsync error: errors selecting input/output files, dirs (code 3) at main.c(729) [Receiver=3.1.2]
2023/12/21 21:37:00	End service_restore
2023/12/21 21:37:00	Begin syno_sync_var_folder
2023/12/21 21:37:00	End syno_sync_var_folder
2023/12/21 21:37:00	upgrade cops 1.5.4-8 End postupgrade ret=[0]

Taking a look at the synopkg.log file we see the following around the same time:

2023/12/21 21:36:58 Acquire systemd-unit for cops when 0x0002 (ready)
2023/12/21 21:36:58 Acquire systemd-unit for cops when 0x0002 (done)
2023/12/21 21:36:58 Acquire data-share for cops when 0x0002 (ready)
2023/12/21 21:36:58 Acquire data-share for cops when 0x0002 (fail)
2023/12/21 21:36:59 upgrade cops 1.5.4-8 Begin postinst
2023/12/21 21:36:59 upgrade cops 1.5.4-8 End postinst ret=[0]
2023/12/21 21:36:59 upgrade cops 1.5.4-8 Begin postupgrade
2023/12/21 21:37:00 upgrade cops 1.5.4-8 End postupgrade ret=[0]
2023/12/21 21:37:00 upgrade cops: begin to start version 1.5.4-8
2023/12/21 21:37:00 Installing flag of [cops] exists.
2023/12/21 21:37:00 upgrade cops: start version 1.5.4-8 failed, result 0
2023/12/21 21:37:00 upgrade cops from 1.4.2-7 to 1.5.4-8 failed

From what I could tell, because the acquisition of the data-share failed, the web folders were not installed and as such, the service restore could not copy the backed up files, producing errors. I've proposed an upgrade wizard which will help define the data share name when needed to avoid failures with the data-share acquisition.

[hgy59]

@mreid-tt good work!

I can confirm that the update from 1.4.2-6 to 1.5.4-9 works.

The update from a broken 1.5.4-8 version to 1.5.4-9 does not work.
In this case, the share is working as expected, but there are missing files to restore:

2023/12/22 10:07:54     ===> Step postupgrade. STATUS=UPGRADE USER=cops GROUP=http SHARE_PATH=/volume1/calibre
2023/12/22 10:07:54     Begin service_restore
2023/12/22 10:07:54     Restore previous data from /volume1/@tmp/synopkg.tmp/cops/cops
2023/12/22 10:07:54     rsync: link_stat "/volume1/@tmp/synopkg.tmp/cops/cops/web/config_local.php" failed: No such file or directory (2)
2023/12/22 10:07:54     rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1464) [sender=3.1.2]
2023/12/22 10:07:55     rsync: link_stat "/volume1/@tmp/synopkg.tmp/cops/cops/web/.htaccess" failed: No such file or directory (2)
2023/12/22 10:07:55     rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1464) [sender=3.1.2]
2023/12/22 10:07:55     End service_restore
2023/12/22 10:07:55     Begin syno_sync_var_folder

To make it bullet proof, the config_local.php and .hataccess files have to be recreated if missing in a package update.

I was always wondering why the package Repair does not work. This can give a hint to improve the update process for other packages.

PS: all testing done on DSM 7.2.1

[mreid-tt]

To make it bullet proof, the config_local.php and .hataccess files have to be recreated if missing in a package update.

Thanks for your review. For the php config file there are a number of options which are setup initially as part of the install. I would have to either assume default values for the configuration or re-present the install wizard screens for the user to re-set those values. Do you have a preference for which?

EDIT: I've implemented a re-create from defaults strategy rather than prompting the user and it seems to work in my tests on DSM 7.