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