#412 GNOME File-Roller working with p7zip[-full] but not with 7zip

[Raistlin]

In openSUSE Tumbleweed, we are switching from p7zip[-full] to 7zip. We've had the problem that GNOME's Archive Manager (aka File-Roller, https://gitlab.gnome.org/GNOME/file-roller), which was able to handle well password protected 7z files with p7zip-full installed, can no longer do so with 7zip installed.

The issue seems specific to archives for which the listing of their content is passowrd-protected. Some details are available here: https://bugzilla.suse.com/show_bug.cgi?id=1195041

I've done some debugging and what I was able to figure out is that in p7zip, Open_CryptoGetTextPassword() does not fail (or, at least, not in a way that causes its callers to raise an exception). This leads to File-Roller being able to identify that a password is necessary for listing the content of the archive, and it asks for it to the user.

In 7zip, instead of (or, shall I say, in addition to) of GetPassword(), you have GetPassword_HRESULT(). If my understanding is correct, when 7z l ... filename.7z is called from within File-Roller (and for an archive for which listing its content is also protected), that function returns E_ABORT. And since 7zip calls the function like this RINOK(GetPassword_HRESULT(_so, Password));, what happens is that Open_CryptoGetTextPassword returns immediately, an exception (for a break) is thrown, and 7z terminates with 255 as its exit status (In fact, I can see this from inside File-Roller, by adding a few debug printf-s). And this behavior is not something that File-Roller recognizes as "Hey, maybe there's a password for listing, let's ask the user!". :-)

If, as a workaround, I get rid of the RINOK() wrapper around the invocation of GetPassword_HRESULT(), File-Roller starts to work fine, as it was with p7zip.

Now, I'm not really sure whether it is 7zip or File-Roller that should be fixed. My understanding (but I may be wrong!) is that 7zip wants to be a fully compatible, drop-in replacement of p7zip, and that's why I'm reporting the problem here (as, currently, this is not the case, at least for the specific use case of File-Roller trying to handle this kind of password protected 7z archives).

Furthermore, even if it is actually be the case that it's 7zip that needs to be fixed, it's pretty possible that the downstream patch that I am proposing for openSUSE's 7zip package (attached here as well, for convenience) is not the best way for dealing with this issue. The thing is, I needed something quick to get File-Roller working again, and I had never even glanced at the source code of either File-Roller and 7zip before... So that's what I've been able to come up with in a few hours.

Hopefully, however, reporting the issue here --and maybe even the analysis that I have done and that I have tried to outline above-- would still be useful