I have a question about creating a 7z file with symbolic links in Linux.

[whitelazy]

I've encountered an issue with symbolic links not being created correctly when including files with symbolic links.

My testing environment is as follows:

Ubuntu 22.04
7zip: 23.01
bit7z: release/v4.0.0

I also tried building 7za from 7zip 23.01 source for testing, and I encountered the same issue when creating files with symbolic links. To include symbolic links correctly, I had to use the "-snl" switch during creation:

Even when attempting to use bit7z::BitAbstractArchiveCreator::setFormatProperty, it only raises an exception stating, "The parameter is incorrect."

Decompression of a 7z file that includes symbolic links proceeds successfully.

Is there a way to pass the 'snl' switch to the 7z library?

[rikyoz]

Hi!
Yeah, unfortunately, the -snl switch isn't available within the 7-zip DLL, so this functionality must be implemented in bit7z.

The good news is that I just pushed a commit to the release/v4.0.0 that implements it (929ab74)!
By default, it is disabled (to keep the same behavior as old versions of bit7z), so I've added a setStoreSymbolicLinks(...) method to BitAbstractArchiveCreator that can be used to enable it.
From my test, it seems to work just like the -snl switch of the 7z program.

I hope it works well!

Thank you for pointing it out!

[whitelazy]

Thank you. I will test it!!

[whitelazy]

I attempted a test to compress a directory that includes symbolic links using the commit you provided. I encountered some issues, so I'm asking again.

1. Test Method (bash on Ubuntu 22.10):

mkdir testdata
cd testdata
echo "TEST" > test.txt
ln -s test.txt testln

2. using 7za

7za a -snl test_7za.7z

3. using bit7z

bit7z::BitFileCompressor compressor(lib, bit7z::BitFormat::SevenZip);
compressor.setCompressionMethod(bit7z::BitCompressionMethod::Lzma2);
compressor.setStoreSymbolicLinks(true);
compressor.compressDirectory("/home/ayhmi/projects/testdata/", "test_bit7z.7z");

This is the result of examining two files with BitArchiveReader.

"/test_7za.7z"
"Item[0] : testdata"
	 3 "Path" "testdata"
	 6 "IsDir" "true"
	 7 "Size" "0"
	 8 "PackSize" "0"
	 9 "Attrib" "1107132432"
	 12 "MTime" "31056408, 2328767232"
	 15 "Encrypted" "false"
	 21 "IsAnti" "false"
"Item[1] : testdata/test.txt"
	 3 "Path" "testdata/test.txt"
	 6 "IsDir" "false"
	 7 "Size" "5"
	 8 "PackSize" "17"
	 9 "Attrib" "2176090144"
	 12 "MTime" "31056408, 2278767232"
	 15 "Encrypted" "false"
	 19 "CRC" "4152612798"
	 21 "IsAnti" "false"
	 22 "Method" "LZMA2:12"
	 27 "Block" "0"
"Item[2] : testdata/testln"
	 3 "Path" "testdata/testln"
	 6 "IsDir" "false"
	 7 "Size" "8"
	 9 "Attrib" "2717876256"
	 12 "MTime" "31056408, 2328767232"
	 15 "Encrypted" "false"
	 19 "CRC" "3066643579"
	 21 "IsAnti" "false"
	 22 "Method" "LZMA2:12"
	 27 "Block" "0"

"test_bit7z.7z"
"Item[0] : testdata"
	 3 "Path" "testdata"
	 6 "IsDir" "true"
	 7 "Size" "0"
	 8 "PackSize" "0"
	 9 "Attrib" "1107132432"
	 12 "MTime" "31056408, 2328767232"
	 15 "Encrypted" "false"
	 21 "IsAnti" "false"
"Item[1] : testdata/test.txt"
	 3 "Path" "testdata/test.txt"
	 6 "IsDir" "false"
	 7 "Size" "5"
	 8 "PackSize" "9"
	 9 "Attrib" "2176090144"
	 12 "MTime" "31056408, 2278767232"
	 15 "Encrypted" "false"
	 19 "CRC" "4152612798"
	 21 "IsAnti" "false"
	 22 "Method" "LZMA2:12"
	 27 "Block" "0"
"Item[2] : testdata/testln"
	 3 "Path" "testdata/testln"
	 6 "IsDir" "false"
	 7 "Size" "5"
	 8 "PackSize" "9"
	 9 "Attrib" "2717876256"
	 12 "MTime" "31056408, 2328767232"
	 15 "Encrypted" "false"
	 19 "CRC" "4152612798"
	 21 "IsAnti" "false"
	 22 "Method" "LZMA2:12"
	 27 "Block" "1"

I've discovered that during the compression process, when requesting the size of a file, it returns the size of the file that the symbolic link points to, rather than the size of the symbolic link itself (which is typically 8 bytes). I attempted to modify the 'size()' function in the FSItem class to use 'lstat64()' when dealing with symbolic links, but it seems that symbolic link handling is not fully implemented.

In compressed files created using 7za, symbolic link files are not compressed; they are stored as 8 bytes, and the Block attribute is set to 0, not 1.

Can you provide any assistance with this issue?

[rikyoz]

I've discovered that during the compression process, when requesting the size of a file, it returns the size of the file that the symbolic link points to, rather than the size of the symbolic link itself (which is typically 8 bytes). I attempted to modify the 'size()' function in the FSItem class to use 'lstat64()' when dealing with symbolic links, but it seems that symbolic link handling is not fully implemented.

Yeah, 7-zip seems to handle symbolic links differently according to the archive format.
In particular, my recent change to bit7z seems to work for tar archives but not for the 7z format, which doesn't read the symlink property at all for some reason.

I'm trying to find how the 7z format handles symbolic links, and I'll release a fix for this as soon as possible.

[rikyoz]

Hi!
I just pushed a commit that should fix the handling of symbolic links in 7z archives (2de9981).
Now, bit7z doesn't follow symbolic links if you call setStoreSymbolicLinks(true), which was the issue.
As a side note, now enabling storing symbolic links also sets the solid compression mode to true, which is the same behavior of 7-zip/p7zip.

Let me know if it works for you!

[whitelazy]

Hi!
I tested the commit (2de9981) today.

Your changes work very well.

Thank you.

[rikyoz]

Perfect, you're welcome!

Thank you for using bit7z and for the donation, I really appreciate it! 🙏