* Legacy Backup and Restore FH Settings plugin does not run in Linux/WINE

[Mark1834]

I suggest that a more general discussion of coding for emulator compatibility is best held over until we have the first draft of the KB page, which I’ve deliberately held fire on pending resolution of this specific issue. However, I think we’re there now so I’ll post something next week.

I think I’ll also expand the comparison between the two plugins and what they do in the KB, as there still seems to be confusion around exactly how they function, where you definitely need them and where they are just a convenient alternative to other (better) ways of doing exactly the same thing that are open to more advanced users.

[Valkrider]

As shown by Colin's experiments, it is not just Linux/WINE that is affected but also Crossover.
I'm not sure whether that was Crossover on Linux or a Mac.
Perhaps, PlayOnLinux/Mac also needs to be examined.

Mike

I used Crossover on Mac. I now have a Silicon rather than Intel Mac and PlayOnMac no longer runs successfully on Silicon so am unable to test for you sorry.

[ColeValleyGirl]

OK, so we have learnt something not mentioned before, that WINE folders support a much smaller subset of FSO attributes than WINE files. Presumably, that will be fed into the updated fhFileUtils.fh_lua library.

New library was released with 7.0.23 that addresses this issue.

[tatewise]

Mark, I have updated my Backup and Restore Experiments plugin to not only check folder & file attributes but also determine the OS by detecting Z:\bin & Z:\etc and run a batch script using REG EXPORT.
Could you please run it in Windows and Unix/WINE. Colin could you try Crossover.
Download link: https://1drv.ms/u/s!ArcYtrv6ufQpo6gu24T ... A?e=6G6Eha

It should simply report:
Get Folder Attributes OK.
OS seems to be Windows. or OS seems to be Unix/WINE.
Batch Script REG EXPORT OK. or Registry Export Error ERROR: Registry Key data not saved ...

The batch script functions are lifted from my Backup and Restore FH Settings plugin so are quite complex.
It should clean up its temporary Family Historian files & folder which are created in the project's Public folder.
I don't expect you to debug anything if it fails.

[Valkrider]

Mike

Fine under Crossover on Mac works as you expected with 2 OK's and one correctly identified OS.

[Mark1834]

Works as expected in Linux Mint / WINE 9.0 as well.

Picking up other comments, the next draft of the Windows backup plugin will also adopt that approach to detecting WINE - if both Z:\etc and Z:\bin are present, it is in WINE, otherwise it is Windows. I will ignore the Compatibility Mode setting for reasons discussed in the KB, as looking for these files is sufficient.

I am also taking the opportunity of tidying up temporary files. At the moment, scripts created in normal backup/restore mode are saved with temporary names in the Plugin Data folder (e.g. \Plugin Data\~fhBackup.bat, etc.). I think it is better to use the Lua temporary file functions, either io.tmpfile() or os.tmpname(). The former is preferred for files that are used entirely within the plugin and discarded after use, as by definition they are simply handles that are deleted automatically and may not even be physical disc files. Where I need a defined file name (say to run a script after FH closes), it has to be os.tmpname(), but that has the advantage of returning a temporary file name in the users AppData\Local\Temp folder. If anything goes wrong with the plugin and it doesn't delete the file, it is safely out of the way in a standard temporary location rather than cluttering up either an FH folder or the user's project folder.

Have you tried that approach and rejected it for some reason?

Incidentally, it also raises another Windows/WINE difference that I will add to the KB - under WINE, os.tmpname() simply returns a suitable file name, but without the full path. If I continue this approach, I'll probably have to create my own temporary folder, but I think I still prefer that over using either an FH folder or the user's project folder.

[tatewise]

That is good news and allows me to update and vastly simplify my Backup and Restore FH Settings plugin.

I tend to put files in C:\ProgramData\Calico Pie\Family Historian\Plugin Data\ with the plugin filename.
They may be global sticky settings, temporary files, etc. The path ensures there are no unusual UTF-8 chars.
They are mostly only a few KB each and the same file gets reused each time the plugin runs.

I recall using os.tmpname() but it behaves differently in Lua 5.3 and Lua 5.1. ( Not sure about io.tmpfile(). )
Lua 5.3 includes the full path and Lua 5.1 does not. So for backward compatibility with FH V6 it gets awkward.

[Mark1834]

Agree users with Unicode names could present a problem, as that is unlikely to be supported in the Lua libraries. I do think it's important to distinguish clearly between things that should be in FH folders and user data folders (plugin settings, etc), and residue left over from a malfunctioning plugin, so it's worth a bit more work to define.

There's no issue with io.tmpfile() - it's a handle, not a file, so the OS will keep track of it automatically using whatever designation it assigns.

I'll need to think about how to handle os.tmpname() for the less common scenario of needing a named file. For the large majority of cases (Windows users with non-Unicode names and FH7), it's straightforward, but for most of the rest it should be possible to work out where the tmp folder is and construct the full path manually.

I'm at risk of drifting off from this thread's main focus, as you don't maintain this distinction, but I'll post any updates that need further discussion later in a more appropriate place.