Family Historian User Group

The Microsoft File System Object (FSO) method Get Parent Folder Name(path) returns a string containing the name of the parent folder of the last component in the specified path.
That is used throughout the fhFileUtils library functions and specifically in the function getParent(sPath).
It works perfectly correctly even for paths incorporating extended Unicode characters such as ĀĒĪŌŪ.

( BTW: I have had to insert space characters into Get Parent Folder Name to avoid Forum error 404. )

I have written library functions of my own that are effectively copies of the fhFileUtils library functions.
They all work perfectly correctly when used in FH v7.

They also all work perfectly correctly when used in FH v6 except for Get Parent Folder Name(path) when there are extended Unicode characters such as ĀĒĪŌŪ in the path.
i.e.
require("luacom")
fso = luacom.CreateObject("Scripting.FileSystemObject")
strParent = fso:Get Parent Folder Name(strPath)

works correctly except when strPath is such as:
E:\Mike\Documents\Family Historian Projects\Unicode ĀĒĪŌŪ\Unicode ĀĒĪŌŪ.fh_data\Plugin Data\text.dat
then it returns the strParent path:
E:\Mike\Documents\Family Historian Projects\Unicode ĀĒĪŌŪ\Unicode ĀĒĪŌŪ.fh_data\P
and if its parent is obtained various other invalid paths are returned.

Further testing reveals that the Get Folder list function suffers the same problem:
local tblList = fso:GetFolder(strFolder)

The invalid path is caused by a strange string length miscalculation.
For each multi-byte UTF-8 code point, the file path string is reduced by one byte.
So if it contains 5 two-byte UTF-8 code points, the file path string is truncated and loses its last 5 characters.

It is as if the path string length is determined by the number of code points rather than the number of bytes.
The path is then truncated at that length and some trailing bytes/characters get discarded.

I've tried testing with Plugin Encoding 'ANSI' and 'UTF-8' and with and without the 'compat53' and 'utf8' libraries.
All the other FSO methods perform perfectly.

I know it is a niche application but has anyone any other ideas?

Any difference in the Windows version between your FH6 and FH7 testing environments? It is, after all, unlikely to be an FH version issue.

Also, the .Net version.

They are both the same latest Windows 10 Home Version 21H2 OS Build 19044.1466
They both run AS V7 so presumably have similar .Net versions. Where do I check .Net version?

I always look in Programs and Features, although there's probably a better way to do it.

What happens if you call the same objects by a completely different route, such as Excel VBA? Do you still get the same difference between PCs?

I've checked that the same .Net features are installed on both PC, but still no better.

I've started to try and run some VBA on both PC but VBA script does not seem to allow literal Unicode strings such as:
"ĀĒĪŌŪ"
So I cannot use a VBA command such as
Set fs = CreateObject("Scripting.FileSystemObject")
Set a = fs.GetParentFolderName("C:\Test\ĀĒĪŌŪ\Sub")

However, the following works in Windows Powershell perfectly on both PC:
(New-Object -ComObject Scripting.FileSystemObject).GetParentFolderName("C:\Test\ĀĒĪŌŪ\Sub")
producing
C:\Test\ĀĒĪŌŪ

So the only environment that fails is in FH V6 Lua 5.1 plugin scripts!

Any difference between running in the debugger and not.

Is there a way of running the two versions of Lua completely independently of FH to check whether it is a characteristic of that language version, or the FH interface is somehow involved?

Mark, if you use something like Zerobrane or Visual Studio Code with a standalone version (or versions) or Lua, yes it's doable. I haven't bothered to set up an environment like that because it isn't often needed -- most of the time you actively want to test in the FH environment because that's the target.

The problem is the same whether the plugin script is run normally or in the debugger.

The laptop that has the problem (Windows 8.1 vintage) is actually newer than the desktop (Windows 7 vintage) that works, which further suggest it is FH V6 Lua 5.1 related, but how?

I don't fancy trying to run a standalone version of Lua for the reasons Helen states. It might not even be exactly the same build of Lua 5.1 as is built into FH V6.

If there is no workaround, then some functionality will need to be inhibited in my plugins when running in FH V6.

The fso.GetParentFolderName(...) function does have a workaround involving string.match(...) when necessary because no actual file system interaction is involved.
But the fso:GetFolder(...) function does interact with the file system so there is no foolproof workaround.

Mike, clutching at straws, but are you using compat53 and utf8 libraries in your FH6 environment? And have you tried playing around with those to see what makes a difference?

I can't think of anything else that might be involved.

As I said yesterday evening:
"I've tried testing with Plugin Encoding 'ANSI' and 'UTF-8' and with and without the 'compat53' and 'utf8' libraries."

I'm sorry -- I missed that.

In which case, I'm out of ideas.

If you post a complete script that demonstrate the problem, I can run it in my V6 testing environment... might demonstrate that it's a general problem, or one confined to a single environment. (Yes, another straw, but it might help).

My very first posting effectively provides the script but this will demonstrate the problem: That should return C:\Root\Unicode ĀĒĪŌŪ but actually reports C:\Root\Unicode ĀĒ? truncated by 5 bytes.

Similarly, the list returned by fso:GetFolder("C:\\Root\\Unicode ĀĒĪŌŪ\\Folder") has similar problems but you need an actual folder with those Unicode code-points in the path name.

The problem isn't specific to your environment -- I can reproduce the error in FH6/Windows 10.

Thank you for confirming the problem.
I guess there is nothing to be done as CP are not going to retrospectively fix whatever is the cause in FH V6 Lua 5.1.

You could try using the File Object and its ParentFolder Property. Haven't tested it myself.

There are several problems with using fso:GetFile(strFileSpec) instead of fso:GetParentFolderName(strFileSpec)

1. strFileSpec may not exist yet. The purpose of the test is to check if the parent folder exists before creating the file.
2. strFileSpec may be a File or a Folder. So choosing fso:GetFile(strFileSpec) or fso:GetFolder(strFileSpec) is a dilemma.
3. The following code suffers the same problem with file name truncation in FH V6:

   Code: Select all

   require("luacom")
   local fso = luacom.CreateObject("Scripting.FileSystemObject")
   local tblList = fso:GetFile(strFileSpec)
   local tblName = tblList.ParentFolder.Name
   

I suppose you could get clever with the luacom error handling ,turning off abort on error and inspecting last_error.

Illustration of techniques:

Yes, that might resolve point 2. but I don't see how it would resolve points 1. and 3. ?
i.e. Point 3. exhibits the same fault we were trying to circumvent!

I've posted an issue with the LuaCOM developer for any advice: https://github.com/davidm/luacom/issues/26