Hello Fred,
this is a follow-up to my message on Wed, 6 Sep 2023 00:24:37 +0200.
Although it's unfortunate that you didn't have the directory and stat file
for storage of MSEclock's settings, this might not neccessarily have lead
to an error. The stat file mechanism DOES already have an option
(sfo_createpath) to silently create both path and file when set - the
reason it didn't is simply that I was unaware of that option and so it
was left unset. Perhaps the option should be set by default for non-memory
resident stat files?
If the option had been set and everything else were right, MSEclock would
not have shown an error message and simply created the state file silently.
But not everything IS right in the line of actions running for that
purpose. I did some investigation on behalf of introducing an automatic
file - and directory - creation function as you requested (which turned
out not to be required anyway), and found a blatant error in a quite
deeply entrenched unit for file and stream operations. So, even with the
before mentioned option set, the creation of a stat file would have failed,
failed silently, and thus probabely given the impression that the state
mechanism didn't work...
The cause is located in unit "msesysintf", function "sys_openfile". This
should open a file of a given name and return an error code and a file
handle. Well. It does, but - when the file does NOT exist, it returns
"sye_ok", the success code, and an INVALID file handle of -1. But there's
NO check of the validity of the file handle returned after this call, and
so the processing happily calls a number of file access functions that all
fail, without even noticing it. But that doesn't matter, as after that it
sets an internal variable saying that it HAD successfully loaded a settings
file, although in fact nothing at all of that has happened.
The real problem only arises on write back time - then, the writer routine
checks this internal variable to see whether an input file had been
successfully processed, and uses that to write back the new settings.
Well, and, of course, it ALSO FAILS miserably, because there IS NO FILE.
And it doesn't even notice it again, because it runs into the same error
as the reader routine again, where the system function reports that all
was right when in fact it was unable to do anything at all.
The resolution to that failure is not even difficult, a few lines for
testing the handle returned for validity and setting the error result
accordingly do what's needed, and this is accomplished by adding the
following lines to the end of unit file "kernel/linux/msesysintf.pas",
starting at line 710:
/////////////////////////////////////////
IF handle < 0 THEN BEGIN // AN ERROR HAS OCCURRED!
if openmode = fm_create
then result:= sye_write
else result:= sye_read;
END
ELSE BEGIN
//---------------------------------------
fpfstat(handle,stat1);
setcloexec(handle);
result:= sye_ok;
//---------------------------------------
END;
/////////////////////////////////////////
The lines between the two "//-----" lines are already in place, and that
was the only exit path before, thus never reporting an error condition...
There are some minor points of failure in the code following that call,
but they apparently don't do any harm as they just don't do anything at
all, so I left everything other as is, tested the modification, and found
that IT WORKS!
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
_______________________________________________
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
