gtreshchev / runtimearchiver Goto Github PK

l: Error: UAT: 10-31 09:46:12.019 1492 1624 D UE : [2023.10.31-01.46.12:019][687]LogRuntimeArchiver: Error: ERuntimeArchiverErrorCode::NotInitialized: An error occurred while opening zip archive '../../../RedStory/Content/ResourcePackage/23.zip' to read.
what's i miss?

Hello,

It looks like UE's LZ4 setup is just the basic compression, it doesn't contain the required lz4frame library required to generate a file that can actually be opened by lz4 command line tools. As such, I am not able to open the LZ4 files generated by your plugin. Is there any way you've managed to open them? If not, it's probably worth documenting this.

Thanks!

[2024.01.25-14.38.45:392][359]LogRuntimeArchiver: Error: ERuntimeArchiverErrorCode::ExtractError: Unable to extract zip entry 'SaveGameInfoJSON.txt' into memory.
Miniz error details: 'invalid header or archive is corrupted'.

the issue is this:
i am using

	UFUNCTION(BlueprintCallable, Category = "Runtime Archiver|Open")
	bool OpenArchiveFromMemory(TArray<uint8> ArchiveData);

but there are several problems with this function as written:
1 - it makes a temporary copy of the archive data
2 - it makes a second temporary copy in

bool URuntimeArchiverBase::OpenArchiveFromMemory(TArray<uint8> ArchiveData)
{
	return OpenArchiveFromMemory(TArray64<uint8>(MoveTemp(ArchiveData)));
}

that copy gets destructed on the way out of OpenArchiveFromMemory, which ends up freeing the memory for the temporary copy and overwriting the first four bytes of the archive data

that makes the first file unreadable, of course ( it appears corrupted because it is missing a proper signature ) but of course the problem is worse than that since the whole block has been free and a raw pointer to it stored in MinizArchiver->m_pState.m_pMem

I can hack arounds this by changing

	UFUNCTION(BlueprintCallable, Category = "Runtime Archiver|Open")
	bool OpenArchiveFromMemory(const TArray<uint8> &ArchiveData);

and

bool URuntimeArchiverBase::OpenArchiveFromMemory(const TArray<uint8> &ArchiveData)
{
	const TArrayView64<const uint8> ArchiveData64( (const uint8 *) ArchiveData.GetData(), ArchiveData.Num());

	return OpenArchiveFromMemory(*reinterpret_cast<const TArray64<uint8>*>(&ArchiveData64));
}

but that is kind of a rickety abomination

when using RuntimeArchiver to unzip a zipfile, two scene would cause problem:

1. zip file created from Mac OS,with Chinese characters filename, then unzip the file on Windows;
2. zip file crated from Windows ,with Chinese characters filename, then unzip the file on Windows.

scene 1 problem : filename encoding is UTF-8, but Windows use GBK to decode.
scene 2 problem : filename encoding is GBK,but RuntimeArchiver use UTF8_TO_TCHAR to parse m_filename,which is wrong for Chinese characters,may use MultiByteToWideChar to solve scene 2 problem

It seems there is no good way to detect which scene is ,except detect the filename endoding format