Is kismet-analyzer blocking itself from opening the .usmap file?

[igromanru]

After extracting IoStore Container files with new ZenTools for UE 5.3-5.4 I hopped to get kismet-analyzer working with Blueprints.
And indeed it went much father than before.
But now it fails with error:

---> (Inner Exception #8) System.IO.IOException: The process cannot access the file 'D:\Data\Datamining\Abiotic Factor\v0.9.1.11753\Mappings.usmap' because it is being used by another process.

It happens directly after:

Warning: UTF8 codes > 4 bytes are not currently supported (graph %1) - treated as Latin-1. Perhaps "-Gcharset=latin1" is needed?

So I'm not sure if it's the cause of it.
Here is the full log:
output.txt

I double-checked that the path to all files exists and requires no admin privileges to access.
Also I checked that nothing accesses the Mappings.usmap before executing the command with LockHunter.

[trumank]

Should be fixed, but untested.

[igromanru]

Same problem here now:

kismet-analyzer/Program.cs

Line 348 in 118751a

UAsset asset = LoadAsset(ueVersion, mappings, assetPath);

Correct me if I'm wrong, but shouldn't a UsmapBinaryReader or the MemoryStream that is used by it be disposed at the end?
I mean the whole code it build around new Usmap(mappings)

public Usmap(string path)
{
    this.FilePath = path;
    Read(PathToReader(path));
}

public UsmapBinaryReader PathToReader(string p)
{
    return new UsmapBinaryReader(PathToStream(p), this);
}

But Usmap has no Close or Dispose? Am I missing something?

[trumank]

Oops, missed the second one. Usmap shouldn't be keeping the handle open after it's read. Since it's being done in parallel it's just parsing it multiple times and locking itself out.

Oh I see UAssetAPI might not be closing it, though I'm not super familiar with how C# handles work.

[igromanru]

Yes, Usmap should derive from IDisposable and implement the interface to call Dispose() from UsmapBinaryReader.

EDIT: Thanks, the current problem is fixed so far.