Thank you, I'll try it.
I tested Multiarc with your 7z addon, unfortunately there are no bugs with debug version, or with release one with debug info enabled. However if I disable debug info, I get access violation and see that Multiarc calls some function from shell32.dll...
Strange, if I comment line with
GetCurrentDirectory call, it crashes, however its returned value is not used more:
Code: Select all
bool CArchiverEngine::OnClose()
{
bool bRet;
if(m_pad->BatchUnpack() && m_pDeferedNames)
{
char szCurPath[ MAX_PATH ], * tmp, * workDir=0;
GetCurrentDirectory(MAX_PATH,szCurPath);
And problem occurs somewhere inside of
delete_files call:
Code: Select all
if( bRet )
{
move_files( tmp, m_pStripPath, m_pDestPath );
delete_files( tmp );
}
Which calls
SHFileOperation... It seems that error have been caused because not all fields of
SHFILEOPSTRUCT structure have been filled (floating bug which become visible only after my changes).
deus-ex,
Please test next build, it shouldn't cause crash, also I fixed UHARC problem, please try it with all your packers.
MVV Build #7 32+64
And don't forget that since #4 you can replace 256
n's with just
n++.
Hurdet wrote:Why this:
Format0="yyyy tt dd hh mm ss a+ zzzzzzzzzzzz pppppppppppp n+"
work and this:
Format0="yyyy tt dd hh mm ss a+ z+ p+ n+"
not?
I'll describe this. Second one doesn't work because
"z+" stops at first space, but since 7z prints numbers right-aligned, for small numbers
"z+" will stop immediately (there are a lot of spaces before number). However you can use
" +z+" (note space before first
+) and it will work because
" +" will skip all spaces before number.
However I just noticed that 7z may simply omit (fills with spaces instead of printing any number) packed size value in case of solid compression so
"z+" will skip all spaces until filename and it will cause parse error (because of shift packed size will be read from filename and filename will be empty). Finally I changed 7z format string to this one to bypass such cases:
Code: Select all
Format0="yyyy tt dd hh mm ss aaaaa zzzzzzzzzzzz pppppppppppp +n++"
However I don't know how 7z lists files larger than 1 TB. UnRAR simply makes that field longer when number of digits is insufficient, this produces shifts, and it was the main reason to introduce
+ sign:
zzzzzzzzzzzz+ will read at least 12 digits (but it will read more until first space in case of huge numbers).
