rikyoz
commented
7 years ago It's no bother at all! I've made some experiment and I have noticed this problem too! Technically speaking, the file callback is (should be?) called whenever a new file stream is requested by the 7-zip dll. Now, it could be either a bug of 7-zip or bit7z executing the callback at the wrong time (or some other problem that at the moment I can't figure out). Since 7-zip doesn't have a good documentation and it has a poor code quality/style (imho), it has been quite hard to understand how it works, hence it is possible that I've made a mistake on where to put the call to the callback! Anyway, I'll investigate this issue and try to figure out how to solve it, if possible.
Edit: I've tried the same experiment with 7-zip File Manager and it has the same problem! Therefore, it should be a bug of 7z.dll and not of bit7z!
EruditePig
Hi,
Sorry to bother you again.
I know the callback mechanism could not guarantee the filename which file callback return to you is the real time file been compressed. But I make a scenario that a large file(take more than 20s to compress) and a small file. And the file callback give me the large file first and immediately give me the small file and then it takes 20s until the program end.
I think the file callback should guarantee that if the 7z is compressing a large file , the last filename retrieved from the file callback is the large file.
If I made any mistake and get the wrong conclusion, I apologize and hope you can point out.
Thank you!