odd behavior with busybox crond

[jazzbiker]

@Greg Erskine
Thanks for testing, behavior is the same as for x86. The proposed patch very likely will stabilize mydata.tgz ownership for PiCore too.

I played a little with backup_done and backup_status files. The main idea that I've gathered is that no matter what user is running "filetool.sh -b". The message about permission violation is issued by

Code: [Select]

t_o_u_c_h /tmp/backup_done
and doesn't affects the backup functionality. Even if You see it (though it is not very pleasant) backup is being performed successfully and exit code is 0. In other words if backup_done was created by root, an attempt of non-privileged user to touch it will fail, but this means that file exists, so the touch goal is reached. I propose simply suppress the error message like:

Code: [Select]

t_o_u_c_h /tmp/backup_done 2>/dev/null
What's Your opinion?

[CentralWare]

Code: [Select]

* * * * * su -c "filetool.sh -b" tcJust run the CRON job "as" the TC user - permission issues solved

[Greg Erskine]

@jazzbiker

I should have mentioned that I tested on piCorePlayer not piCore, but it should the same. Our kernel version usually differ.

As I don't use standard piCore, tinycore, dCore etc it would not be right for me to suggest changes that I haven't tested properly.

For piCorePlayer we just have a function called pcp_backup that handles anomalies.

[jazzbiker]

@Greg Erskine

Thanks for the tip! I think kernels difference may have no influence, busybox tar behavior is pace-maker. Anomalies are to fly away

Have a nice piCorePlayer