You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After making the new backend work successfully with smaller archives, I stumbled upon a weird problem with a larger test file.
Create test files:
# Large archive with two files to test seekability and independence of opened files, which reproduces the bug.> spaces-32-MiB.txt;foriin$( seq $((32*1024)));doprintf'%1024s'$'\n'>> spaces-32-MiB.txt;done> zeros-32-MiB.txt;foriin$( seq $((32*1024)));doprintf'%01023d\n' 0 >> zeros-32-MiB.txt;done
7z a two-large-files.7z spaces-32-MiB.txt zeros-32-MiB.txt
# Slightly smaller file that I accidentally created before because of a bug, which for some reason works fine!> spaces-32-MiB.txt;foriin$( seq $((32*1024)));doprintf'%1023s'$'\n'>> spaces-32-MiB.txt;done> zeros-32-MiB.txt;foriin$( seq $((32*1024)));doprintf'%01023d\n' 0 >> zeros-32-MiB.txt;done
7z a two-slightly-less-large-files.7z spaces-32-MiB.txt zeros-32-MiB.txt
(The slightly smaller version calls printf '%1023s' $'\n' instead of printf '%1024s' $'\n')
Python code triggering the issue
importlibarchivedeflistFiles(path):
print("\nList all entries of:", filePath)
withlibarchive.file_reader(path) asarchive:
forentryinarchive:
print(entry)
forblockinentry.get_blocks():
assertlen(block) >0defreadNthEntry(path, entryIndex):
print(f"\nGet contents of file {entryIndex} of archive: {path}")
withlibarchive.file_reader(path) asarchive:
entryCount=0forentryinarchive:
ifentryCount==entryIndex:
print(entry)
readSize=0forblockinentry.get_blocks():
readSize+=len(block)
print(f" Read file contents: {readSize} B")
entryCount+=1filePath="two-large-files.7z"filePath2="two-slightly-less-large-files.7z"listFiles(filePath) # No errorreadNthEntry(filePath2, 1) # No error# libarchive.exception.ArchiveError: Truncated 7-Zip file body (errno=84, retcode=-30, archive_p=...)readNthEntry(filePath, 1)
List all entries of: two-large-files.7z
spaces-32-MiB.txt
zeros-32-MiB.txt
Get contents of files 0 in archive: two-slightly-less-large-files.7z
spaces-32-MiB.txt
Read file contents: 33521664 B
Get contents of files 1 in archive: two-slightly-less-large-files.7z
zeros-32-MiB.txt
Read file contents: 33554432 B
Get contents of files 0 1 in archive: two-slightly-less-large-files.7z
spaces-32-MiB.txt
Read file contents: 33521664 B
zeros-32-MiB.txt
Read file contents: 33554432 B
Get contents of files 0 1 in archive: two-large-files.7z
spaces-32-MiB.txt
Read file contents: 33554432 B
zeros-32-MiB.txt
Read file contents: 33554432 B
Get contents of files 0 in archive: two-large-files.7z
spaces-32-MiB.txt
Read file contents: 33554432 B
Get contents of files 1 in archive: two-large-files.7z
zeros-32-MiB.txt
terminate called after throwing an instance of 'std::runtime_error'
what(): [Libarchive] Read data failed with: Truncated 7-Zip file body (error code: -30)
Aborted
Observations:
Note that I was very close to reporting this at python-libarchive-c instead of here because I was unable to reproduce the bug with the C++ code at first. It turns out that I forgot the return code check of archive_read_data and it also turns out that ignoring that error (see commented-out code) seems to result in the correct amount of data being returned in subsequent archive_read_data calls!
I had a slightly smaller file at first because of printf peculiarities. Everything works fine with that file two-slightly-less-large-files.7z. It only happens with two-large-files.7z.
It also does not happen when not skipping entries, i.e., when calling archive_read_data for all entries.
The text was updated successfully, but these errors were encountered:
@kientzle So, it works the same as my listFiles implementations, i.e., archive_read_data is not even called and therefore this bug should not happen. I tried it, and it works without error, same as my implementations. It only happens when skipping the first and then trying to read the second entry.
Hello,
Thanks for this widely useful project! I'm trying to incorporate it into ratarmount via python-libarchive-c.
After making the new backend work successfully with smaller archives, I stumbled upon a weird problem with a larger test file.
Create test files:
(The slightly smaller version calls
printf '%1023s' $'\n'
instead ofprintf '%1024s' $'\n'
)Python code triggering the issue
C++ code triggering the issue
Compiled with:
Output:
Observations:
archive_read_data
and it also turns out that ignoring that error (see commented-out code) seems to result in the correct amount of data being returned in subsequentarchive_read_data
calls!two-slightly-less-large-files.7z
. It only happens withtwo-large-files.7z
.archive_read_data
for all entries.The text was updated successfully, but these errors were encountered: