[Bug]: Errors related to file compression

[psvajaz]

bit7z version

4.0.x

Compilation options

BIT7Z_AUTO_FORMAT, BIT7Z_DISABLE_ZIP_ASCII_PWD_CHECK, BIT7Z_USE_NATIVE_STRING

7-zip version

v23.01

7-zip shared library used

7z.dll / 7z.so

Compilers

MSVC

Compiler versions

MSVC2017

Architecture

x86_64

Operating system

Windows

Operating system versions

Windows 7 or later

Bug description

When the comments in the file properties are too long, it can lead to compression errors.
Using 7z can compress normally, but using bit7z for decompression will delete the file's note information.
After manually deleting the note information, bit7z can be used for compression without any errors.
The following image shows the file's properties page:

The following is a complete note:
{"data":{"pictureId":"738298be446d47f4b3933a4cc68ab6a2","appversion":"8.0.0","stickerId":"","filterId":"","infoStickerId":"","imageEffectId":"","playId":"","activityName":"","os":"android","product":"retouch"},"source_type":"douyin_beauty_me"}

Steps to reproduce

No response

Expected behavior

No response

Relevant compilation output

No response

Code of Conduct

• By submitting this issue, I agree to follow bit7z's Code of Conduct

[psvajaz]

How to use the - ssp switch, which was added in the 7-zip version of 20.02

[rikyoz]

Hi!

When the comments in the file properties are too long, it can lead to compression errors.

Uhm, strange, I'll try to replicate the issue!
What are the specific error message and error code (e.g., code() and hresultCode()), if any?

How to use the - ssp switch, which was added in the 7-zip version of 20.02

I'll reply to this in the other issue you created (#184).

[psvajaz]

After testing, it was found that this is an issue with the GHC library, and our project has found that there are some strange issues with the GHC library on the Windows platform. Now we have abandoned the option to enable the GHC library and compiled bit7z into a DLL using vs2019 for the main program to call

[rikyoz]

Hi!
I'm sorry for not getting back to you sooner.

When the comments in the file properties are too long, it can lead to compression errors.
Using 7z can compress normally, but using bit7z for decompression will delete the file's note information.
After manually deleting the note information, bit7z can be used for compression without any errors.

I could not reproduce the problem, at least on develop.
I even added some unit tests to automatically check if the extraction/compression of commented files works. And it does work; I tested it on Windows 7, 10, and 11 with both MSVC 2015 and MSVC 2017.
For the tests, I used the exact same long JSON string for the comments.

bit7z/tests/src/test_bitinputarchive.cpp

Lines 1149 to 1171 in a5e5b87

	TEMPLATE_TEST_CASE( "BitInputArchive: Extracting a file with a comment should preserve it",
	"[bitinputarchive]", tstring, buffer_t, stream_t ) {
	const TestDirectory testDir{ fs::path{ test_archives_dir } / "metadata" / "file_comment" };
	TestType inputArchive{};
	getInputArchive( "commented.7z", inputArchive );
	BitArchiveReader info( test::sevenzip_lib(), inputArchive, BitFormat::SevenZip );
	TempTestDirectory testOutDir{ "test_bitinputarchive" };
	INFO( "Output directory: " << testOutDir )
	REQUIRE_NOTHROW( info.extractTo( testOutDir ) );
	const auto expectedFile = testOutDir.path() / "commented.jpg";
	REQUIRE( fs::exists( expectedFile ) );
	std::wstring comment = get_file_comment( expectedFile );
	REQUIRE( comment == LR"({"data":{"pictureId":"738298be446d47f4b3933a4cc68ab6a2","appversion":"8.0.0",)"
	LR"("stickerId":"","filterId":"","infoStickerId":"","imageEffectId":"",)"
	LR"("playId":"","activityName":"","os":"android","product":"retouch"},)"
	LR"("source_type":"douyin_beauty_me"})" );
	REQUIRE( fs::remove( expectedFile ) );
	}

bit7z/tests/src/test_bitoutputarchive.cpp

Lines 35 to 62 in a5e5b87

	TEST_CASE( "BitOutputArchive: Compressing a commented file should preserve the comment", "[bitoutputarchive]" ) {
	const auto commentedFile = fs::path{ test_archives_dir } / "metadata" / "file_comment" / "commented.jpg";
	BitArchiveWriter writer( test::sevenzip_lib(), BitFormat::SevenZip );
	REQUIRE_NOTHROW( writer.addFile( path_to_tstring( commentedFile ) ) );
	TempTestDirectory testOutDir{ "test_bitinputarchive" };
	INFO( "Output directory: " << testOutDir );
	const auto* const outputArchive = BIT7Z_STRING( "commented.7z" );
	REQUIRE_NOTHROW( writer.compressTo( outputArchive ) );
	REQUIRE( fs::exists( outputArchive ) );
	BitArchiveReader info( test::sevenzip_lib(), outputArchive, BitFormat::SevenZip );
	REQUIRE_NOTHROW( info.test() );
	REQUIRE_NOTHROW( info.extractTo( testOutDir ) );
	const auto expectedFile = testOutDir.path() / "commented.jpg";
	REQUIRE( fs::exists( expectedFile ) );
	std::wstring comment = get_file_comment( expectedFile );
	REQUIRE( comment == LR"({"data":{"pictureId":"738298be446d47f4b3933a4cc68ab6a2","appversion":"8.0.0",)"
	LR"("stickerId":"","filterId":"","infoStickerId":"","imageEffectId":"",)"
	LR"("playId":"","activityName":"","os":"android","product":"retouch"},)"
	LR"("source_type":"douyin_beauty_me"})" );
	REQUIRE( fs::remove( expectedFile ) );
	}

After testing, it was found that this is an issue with the GHC library, and our project has found that there are some strange issues with the GHC library on the Windows platform. Now we have abandoned the option to enable the GHC library and compiled bit7z into a DLL using vs2019 for the main program to call

This is really strange, as GHC is used only for paths and not much else!
Could you provide some more details on what bug did you find in the GHC library?
Thank you!