file callback is not the current compressing file

[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!

[rikyoz]

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]

Haha.

I am really headache with 7zip code. I've tried to read, But i gave up. So i looked up the 7zip wrapper, and i find bit7z. Bit7z is a very nice project, so 加油~~