snapmergepuppy error "unary operator expected"

[glene77is]

#####################################################
#
#(: "SMP" = 'snapmergepuppy'
#(: entered by GlenE77s, 220302-0800

#(: We have attached our BASH mod of the current GITHUB Save2Flash .

#(: Note: 'snapmergepuppy' is a "MERGE" not a true "COPY".
#(: Any pre-existing extraneous data in the saveDATA may remain.
#(: New data will be "MERGED" into the current saveDATA
#(: just as the name implies.
#(:
#(: quoted from system help:
#(: snapmergepuppy is -u, --update
#(: ... copy only when
#(: ... the SOURCE file is newer than the destination file
#(: ... or
#(: ... when the destination file is missing
#(:

#(:
#(: Note: 'snapmergepuppy' Error Message bug
#(: We have noticed that the original 'old' SMP appeared to 'drop'
#(: some system edit changes
#(: if the system was running multiple threads;
#(: ie, resulting edit changes did not appear in the saveDATA on reboot.
#(: We initiated the practice of always running 'save2flash' several times,
#(:
#(: We introduced several repetitions of the SMP call.
#(: We run our edited copy of "/usr/sbin/save2flash" as "rc.z_S2F.sh"
#(: in order to flush the RAM data to the saveDATA.
#(:
#(:----------------------------------------------------------------------
#(:# Now implemented this way in our version of "Save2Flash" code :
#(:# nice -n 19 snapmergepuppy /initrd/pup_ro1 /initrd/pup_rw
#(:#
#(:----------------------------------------------------------------------
#(: 1:
#(: this line in "rc.z_S2F.sh" ( our copy of "/usr/sbin/save2flash" )
#(: [ /usr/sbin/snapmergepuppy /initrd/pup_ro1 /initrd/pup_rw ]
#(: was changed to
#(: [ nice -n 19 snapmergepuppy /initrd/pup_ro1 /initrd/pup_rw ]
#(: in order to inhibit background system procesesses
#(: during the 'snapmergepuppy' run time.
#(:
#(:----------------------------------------------------------------------
#(: 2:
#(: We use GEANY for IDE , and Geany Execute for BASH terminal to test/debug.
#(: We observe the following 'non-fatal' error message
#(: displayed by the BASH terminal during a run on "save2flash" :
#(: "unary operator expected".
#(:
#(: /usr/sbin/snapmergepuppy generates 'non-fatal' error messages,
#(: associated with line # 169, and # 171 inside snapmergepuppy binary file,
#(: This error message can be observed from the terminal mode:
#(: "unary operator expected".
#(:
#(: 3:
#(: First run may have 25 messages.
#(: Second run may have 5 messages.
#(: Third run may have 1 message.
#(:
#(: With this special "save2flash" running 5+ repititions
#(: our edit changes now appear secured in the saveDATA on reboot.
#(:
#(: 4:
#(: Running "sync" before "snapmergepuppy"
#(: does not eliminate his error message.
#(:
#(: 5:
#(: When we enhanced the current 'new distro' '/usr/sbin/save2flash' ,
#(: with the following call:
#(: [ nice -n 19 snapmergepuppy ]
#(: We observed the same non-fatal error message.
#(: We managed this problem with the same repetition method.
#(: Five loops through "snapmergeuppy" appears to cure this problem.
#(:
#(: Similar error message exists in all 8 of our currently running Puppy OS
#(: if we run a raw "nice -n 19 snapmergepuppy" .
#(:
#(: With this special "save2flash" running 5+ repititions
#(: our edit changes now appear secured in the saveDATA on reboot.
#(:
#(:
#(: We have tracked this event through last 7 distros of UpupBB ( up to #29)
#(: and also in Tahr, Xenial, BionicBeaver, FocalFosso, etc.
#(:
#(: 6:
#(: We believe this involves system time requirements to complete system tasks,
#(: before "snapmergepuppy" runs.
#(:
#(: Anybody have a comment:
#(:
#####################################################

[mikeslr]

I don't know enough to know if the following is relevant. The content of your post was several levels above my pay-grade. Just thought your exploration might shed some light on my experience reported here, viewtopic.php?p=51104#p51104 as the terminal output "m is not mounted!" is also a complete mystery to me.

[bigpup]

Woof-CE on Github is really the place to bring up issues about snapmergepuppy
That is where the program code is maintained.

Is the version you are using the latest version?

There are updates to the code, for all the major core programs in Puppy, posted all the time at Woof-CE.
But the updates were probably not available, when the specific Puppy version was produced, using Woof-CE.
I have not checked the snapmergepuppy latest code at Woof-CE.
But maybe the Puppy versions you tested, need to have snapmergepuppy updated with latest version.

Here is the code at Woof-CE
https://github.com/puppylinux-woof-CE/w ... mergepuppy

[retiredt00]

#(: /usr/sbin/snapmergepuppy generates 'non-fatal' error messages,
#(: associated with line # 169, and # 171 inside snapmergepuppy binary file,
#(: This error message can be observed from the terminal mode:
#(: "unary operator expected".

It is a long time that I used puppy with a savefile but I guess you have your reasons.
Looking at snapmergepuppy it seams that lines 169, 171 are actually part of the find command dictating what NOT to merge.
Is this where you get you error, because is hard to see what “unary operator” could be expected there in the absence of any condition?
On the other hand the skipping segment could account for the not merged files you observe.

You nay want to add “set -x” to pinpoint where the errors are coming from

Would also be useful to provide some info on these multi threaded operations. They may generate file place holders but not the actual files triggering the error a bit below at “if [ ! -e "$N" ] && [ ! -L "$N" ] ; then”
Depending on what they are you may want to add some command to wait for their completion before running snapmergepuppy

[glene77is]

to RetiredT00
Thank you kindly for your obviously "experienced" post.
Very helpful to read your logical analysis.
I agree with your conclusion : the "absence of a condition" ... a zero or null could be the trigger.

I realize that nobody else has mentioned this during the last decade,
so certainly not a 'fatal error'.
But,
the just the idea that "snapmergepuppy" was throwing a flag bothered me.

... BTW, "savefile" is the "recommended" method, per BK, written into the standard Install.

...

[glene77is]

to MIKESLR
Thanks for the thought,
and thanks for your honesty.
...
I like that error message you got "m is not mounted!"
Looks like a prepared standard message ,
but certainly as cryptic as a toad's croak !

I am not so great, just have my own skill-set.
... and have lasted five decades and outlived all the egotists.

[glene77is]

to BigPup,
Thanks.
Yes, latest version of everything. BB is v29 now, FF is latest, Slack0 is 7 (still Beta).
UpupBB is the working OS.
But, "snapmergepuppy" looks to be the same code as before.
...
I do read reference material from sources mentioned.
Google, internet forums, and Git are good.
"Woof-CE on Github" is a good suggestion.
I will combine RetiredToo suggestion with others, and pass the baton to them.
...
Keeping a running version of all "official" Puppy Linux OS
is like working a dozen jig-saw puzzles ... just a past-time for am old geeky geezer.
...
Still have copies of my first programs.
My first programs were in Fortran, 1979,on PDP-11.
Then got into research at our University of Tenneesse ,
and did computer interface in Assembler on all the early chip sets.
Long time passing ... passing too soon.
..........................................................

[glene77is]

to RetiredT00,
OK.
We have come to see the Linux and BASH code as part of a grand jig-saw puzzle, with which we can tinker.
Life has come full circle, around to our first perceptions of computers.
***
*** So, we used the "saveDATA.sfs" way back, but got to mucking with our live code,
and found it easier to "run/edit/run again" with a subdir version of "/saveDATA".
*** My utility "CTB" is run everytime we turn around ,
so that we have immediate backups for a quick 'restore prior code' fix.
***
*** The following is an "issue" which occurs during use of "snapmergepuppy".
*** Your Last post reminded me of some "snapmergepuppy" ("SMP") runs
which last upwards of 55 seconds.
Use of the prefix routine "nice" with param "1 thru 19" make no difference.
***
For an example,
IF we boot, select OS, and start my usual editing processes,
THEN the first "SMP" may run 55 seconds. but after that, repeated runs are 1 second or so.
The 'nice' parameter makes no difference.
...
This event is always during use of Linux "snapmergepuppy".
Perhaps we will have to alter the BASH code and echo > SMP.log with date-time-seconds ("DTS") info.
I did run logging on methods on "/usr/sbin/sfs_load" and "rc.sysinit" and "rc.shutdown"
in order to track/study where time was being used during rc.update , sfs_load , rc.sysinit, rcshutdown .
My remedy/work-around is to boot, select OS, run "SMP" first thing.

Next will be GitHub. " https://github.com/puppylinux-woof-CE/w ... mergepuppy "
Have backed up my OS area from SDA1 to backup-TeraByte-Drives.
Have been to GitHub and copied their 'latest' "snapmergepuppy" code as "snapmergepuppy-github.sh".
Have called the new code from GitHub in our own "rc.z_S2F.sh" with run-time splash ,
relabeled "rc.z_S2F-1.sh", included in my list of on-going editing via "MGN" manager..
Now, "snapmergepuppy-github.sh" appears to run rapidly, in UpupBB.
Have placed the "rc.z_S2F-1.sh" link in /root/Startup as "z1-rc.z_S2F-1.sh" (last in the list, ).
Will test again next boot-up and later during an editing session.

22Mar15, have tested the "snapmergepuppy-github.sh" on UpupBinoicBeaver and UpupFocalFossa.
UpupBB runs quickly through the first call to "snapmergepuppy-github.sh".
UpupFF runs 55 seconds through the first call to "snapmergepuppy-github.sh".
Both may or maynot linger up to 55 seconds.

(1) *** We will have to run an A/B comparison of the "previous" and the "github" versions , then we will know.
(2) *** We will have to run an A/B comparison of the UpupBB and UpupFF distros.

*** Any comments / thoughts ?

[glene77is]

22Mar15 thru 22Mar27,
UpDate: Problem Solved

Background:
We have tested the "snapmergepuppy-github.sh" further a hundred times with same timing issues.

Process of our current research : is to run three puppy OS to compare code:
UpupBB BionicBeaver and UpupFF FocalFossa and pupSlacko7 .
We have been comparing the code methods of these three Puppy OS,
rebooting and selecting different OS each time.
UpupBB boots/runs 3 seconds through the first call to "snapmergepuppy-github.sh".
UpupFF boots/runs 55 seconds through the first call to "snapmergepuppy-github.sh".
PupSlacko7 boots/runs 10 seconds through the first call to "snapmergepuppy-github.sh".
On each OS, Subsequent runs of "snapmergepuppy" take about 2 seconds.

Solution found:
The culprit is the attached USB dongle for three additional large USB flash-drives.
Only UpupFF seems sensitive to mounting this dongle with 750G total of data space.

We suspect that "No one is watching the timing of the rc.shutdown ,
and everyone is allowing "rc.shutdown" "asktosave" to handle this issue of "snapmergepuppy" .
So no one sees the extra time involved if you run "snapmergepuppy" first thing with UpupFF .


Our work-around
is to call "SMP" automatically at bootup, ,
by inserting a call-script in the subdir "/root/startup".
This little call script from "/startup" calls gtkdialog to splash a message 'before' and 'after'
showing the time in "seconds" for quick comparison.

quote from "retiredt00"
Would also be useful to provide some info on these multi threaded operations.
They may generate file place holders but not the actual files triggering the error a bit
below at “if [ ! -e "$N" ] && [ ! -L "$N" ] ; then”
Depending on what they are you may want to add some command to wait for their completion
before running snapmergepuppy
/quote
Great insight "retiredt00". Thank you.

Thank you ALL kindly for comments !

rc.z_S2F-1-sh-220323-2100.zip

our mod of the current GITHUB Save2Flash .zip.

(4.94 KiB) Downloaded 75 times

***[/color]

[glene77is]

CAVEAT!
SnapMergePuppy documentation from the system Bash Help files :
Save2Flash calls SnapMergePuppy with the "-u" option .

reading From the system help page:

#(: snapmergepuppy is called with the "-u" --update option
#(: ...copy only when the SOURCE file is newer than the destination file
#(: ... or
#(: ... when the destination file is missing .
#(: