Bugfix for save2flash

[fredx181]

Update 2023-02-01 new version 1.6_1 attached below with some small changes, see info here: viewtopic.php?p=80229#p80229

Update 2023-01-31 Another bug fix, see report from @Phil_54 viewtopic.php?p=80099#p80099 (at 1. , not being deleted symlink after save2flash and rebooted.)
Replaced attachment below, save2flash v1.6 now.
The change is in /usr/bin/snapmergepuppy, scans now for leftover files (by user created and deleted) not only regular files but also symlinks to remove.
=============================================================================================================================================
EDIT 2022-12-10 save2flash package fix (made a bad mistake ) re-attached below v1.5_0

Bugfix for save2flash, new xbps package below.
I thought that save2flash (save on demand or at shutdown) could be trusted, but appears not, sorry.

For who's interested in the details of the problem that I found, here's very simple example how to reproduce the problem:

1) create testdir with 2 files inside
mkdir ~/testdir
cd ~/testdir; touch file1 file2
After reboot saving changes (with save at shutdown enabled), file1 and file2 are in testdir, fine.

2) remove testdir, re-create it and create one file
rm -rf ~/testdir
mkdir ~/testdir
cd ~/testdir; touch file1

Then reboot again saving changes (with save at shutdown enabled) and you'll see that unexpectedly ~/testdir contains again two files, file1 and file2, WTF!, should be only file1 in testdir !

If I had only removed file2 (rather than removing and again creating testdir as in 2) ) it would have been fine.
It happens just because testdir is re-created.

I don't think such a situation happens very very often, however -if it happens- it can lead to big problems I guess, certainly if there are many unexpected 'leftover' files .

Attached save2flash package has a change in script 'snapmergepuppy' that will prevent such behavior, downside is that saving at shutdown or on demand takes longer (depending on the amount of files in the save storage).

DO NOT USE EARLIER ATTACHED V1.4_0 , use v1.5_0 below with fix
==================================================================================================================
EDIT: v1.6 with bugfix, see above. edit later, now v1.6_1 with some small changes:

save2flash-1.6_1.noarch.xbps

save2flash v1.6_1

(4.38 KiB) Downloaded 111 times

EDIT: Newest save2flash .xbps package here: viewtopic.php?p=103651#p103651 (v1.8)

[fredx181]

save2flash fix (made a bad mistake) replaced save2flash above (v1.5_0)
@rockedge sorry, should be fine now, didn't test well earlier

[rockedge]

@fredx181 I am putting the newest version into the rootfs today! I did not change to version 1.0.4 yet so no worries, you caught the problem in time!

Good work Fred.

[fredx181]

Bugfix for save2flash, see info at first post and attachment v1.6

[rockedge]

Installed in KLV-Airedale-rc10

[fredx181]

Updated again save2flash with some small changes, attached v1.6_1 at first post:

- Added on top of /usr/bin/save2flash [ "`whoami`" != "root" ] && exec sudo ${0}
This way when logged in as e.g. spot, it will run with sudo (so it has root privileges, which is required for saving the changes)
But note that this works only for when logged in as a user that's added to the "wheel" group (users spot and weedog are by default on KLV) or for KLU the user must be added to the "sudo" group (users spot and firstrib are already) . So, if you create a new user, add it to the wheel group (KLV) (or sudo group for KLU), OR run sudo save2flash .

- Commented out "set -x" on top of snapmergepuppy script (forgot to do in previous version, it had too much 'verbose' output)

[rockedge]

@fredx181 should I update KLV-Airedale-rc10 with this latest version 1.6.1 ?

[fredx181]

@fredx181 should I update KLV-Airedale-rc10 with this latest version 1.6.1 ?

Well, I'd say not, just small changes, can wait till next rc IMO, but if you think it's important enough ...

[rockedge]

@fredx181 It is worth the effort to put it in. I like to stay up to date with such an important utility script and stay in line with KLU-jamXX and KLA while working on those

Plus I can go to lunch along the Housatonic River with the wife, watch and think about the guys in boats and kayaks fishing for ocean going Striped Bass nice and relaxed knowing that KLV-Airedale is ready to use.

[fredx181]

Another bugfix for save2flash.
Usually I save a session only once (at shutdown) so didn't notice earlier.
What could happen is that when you run save2flash twice (e.g. in the middle of a session and [SAVE] at shutdown) that deleted files or folders that exist by default (part of the rootfs sfs or other sfs loaded at boot) may fail to apply (unexpectedly back after reboot).
Fixed for v1.7_1 attached below xbps package for KLV-Airedale.

save2flash-1.7_1.noarch.xbps

save2flash v1.7_1 bugfix

(4.39 KiB) Downloaded 90 times

The change is in the "snapmergepuppy" script, attached new version for to replace (probably in /usr/bin) in any other KL distro:

snapmergepuppy.gz

Remove fake .gz and make executable

(1.78 KiB) Downloaded 99 times

[fredx181]

Found a small glitch again in save2flash (and another that I can't fix, see below), to explain:
Say you've added a directory in the system (with content inside), saved it and reboot, but later decide to remove this directory, again choose 'Save', then ... after reboot the contents of it are removed OK, but the directory itself stays, so unexpectedly an empty directory is left behind.

Fixed in v1.8, so now the (empty) directory will be deleted too.

save2flash-1.8_1.noarch.xbps

Updated save2flash .xbps package

(4.39 KiB) Downloaded 77 times

(the change is in the "snapmergepuppy" script in /usr/bin)

----------------------------------------------------------

Another problem that may happen (in rare cases perhaps) that cannot be fixed (I think):
Say you delete a directory (with content) that's part of the rootfs SFS (or from another SFS loaded at boot).
Let's take as example in KLV-Airedale the directory /root/Pictures, has content inside folder 'screenshots', delete /root/Pictures and reboot with "Save".
Then /root/Pictures is gone, OK.
But let's say then you create /root/Pictures (as empty directory) again, reboot with "Save".
Expected after reboot is an empty directory /root/Pictures, but it is NOT, it contains again the folder 'screenshots' (as is from the rootfs SFS).

Just simple example. BTW, no such 'problem' when booting with just w_changes=... (without the save on demand option, i.e. changes are saved at real-time).

P.S. I'm not sure if a similar issue was also when using AUFS with save on demand (rather than overlayfs), perhaps there was, but taken for granted

[fredx181]

Updated save2flash .xbps package , change is in /usr/bin/save2flash , according to @wiak's suggestion, see: viewtopic.php?p=116531#p116531

save2flash-1.9_0.noarch.xbps

save2flash v1.9_0

(4.44 KiB) Downloaded 149 times

[rockedge]

@fredx181 Excellent Fred!! You beat me too it....(I was holding my coffee cup)!!

I uploaded it to https://rockedge.org/kernels/data/XBPS_ ... oarch.xbps

I am going to risk it (before @wiak checks it over....) and install it on a work horse KLV-Airedale

[wiak]

Thanks @fredx181 and @rockedge. I actually noticed the recent new save2flash xbps up on rockedge repo before I then visited the forum to read the related posts!