GNOME Bugzilla – Bug 588547
Extracting 7z password protected files fail
Last modified: 2012-05-28 16:42:38 UTC
Please describe the problem: Extraction of files from 7z archive fails on OpenSolaris. Steps to reproduce: 1.Launch file-roller, Click "New" button to create a *.7z file. 2.In "New" dialog, Define file name,save folder. Select "7-zip(.7z)" in "Archive type" drop-down list. Expand "Other Options" and input password in password field. 3.Add a text file to this 7-zip file. 4.Close file-roller. 5.Open created 7-zip file and try to exact. 6. File selection dialog is displayed to prompt to extraction location 7. File Extraction progress dialog is displayed. Actual results: Extraction progress dialog is displayed forever, and nothing is actually extracted. The cancel button is active so you can cancel the extraction however you cannot extract the files. Expected results: Password dialog to be displayed and archive files extracted. Does this happen every time? yes Other information: Performing a "ps" you can see the 7z command is actually running, and it appears to be just sitting there waiting for user response to the password. Killing this process has the effect of the progress dialog disappearing and the password prompt dialog being displayed which I think should be displayed before running the 7z command in the first place. See also : http://bugzilla.gnome.org/show_bug.cgi?id=582917 http://bugzilla.gnome.org/show_bug.cgi?id=490732
looks like this happens only when file-roller is started from a terminal, in that case 7zip waits for the password instead of exiting.
Fixed in master
Just did a git pull of latest master/trunk code to give this a spin, and it's still not working for me (on OpenSolaris). Slightly different behaviour this time around, now instead of progress dialog simply sitting there forever, an error dialog is displayed : ------------------------------------------------------------ An error occurred while extracting files Command exited abnormally. > Command Line Output 7-Zip 4.55 beta Copyright (c) 1999-2007 Igor Pavlov 2007-09-05 p7zip Version 4.55 (locale=en_IE.ISO8859-15,Utf16=on,HugeFiles=on,2 CPUs) Processing archive: /export/home/mattman/matt.7z Enter password (will not be echoed) : ------------------------------------------------------------ Whilst this is better behaviour than a dialog simply sitting there forever it still means extracting encrypted 7z files fails. I've tried this from both command line and via menu launch, outcome is the same.
I cannot reproduce the problem. I've done a temp branch named 'bug-588547' which simply contains some instructions to print debug informations. If you checkout the branch and extract a password protected 7zip archive from the command line, some debug info will be printed to the terminal, paste the output in this bug report so I can see what happens, thank you.
Thanks for looking at this so quickly :) pulled that branch and here's the output : $ ./file-roller /export/home/mattman/matt.7z [1] [2] [2-2] [1] [3] First three lines are printed when file-roller is launching/opening the archive. last two lines are printed when the error dialog is shown.
looks like on solaris the command exits with a different status. I changed the source to just ignore the exit status (which is now printed to the terminal), can you pull and try again?
Definitely getting closer :) Now when I attempt to extract, it shows progress dialog and it tells me : Extraction completed successfully Yet when I look in the extraction location, the files are not extracted at all :(, I would have expected file-roller to display a password prompt dialog ? Output to command line is now : $ ./file-roller /export/home/mattman/matt.7z [1] [2] [2-2] [1] [3] [4] [0] [4] [5] [8] I appreciate your patience here, difficult to debug something from remote :)
So on Solaris the command returns FR_PROC_ERROR_EXITED_ABNORMALLY, and in that case the status was not updated. I changed the source to update the status even in that case, can you please try again?
Did a pull and the outcome including printed result is the same as Comment #7.
Now it explicitly set the status to a non-zero value when the program exits abnormally, this should make it work. Give it another try :)
Yep that did the trick worked a treat... :) thanks a million. Can you email me a diff of the changes that you made so that I can apply them locally here on our stable 2.26 branch and devel 2.27 branches until this makes into a future released tarball.
you can use the following command to get the diff: git diff 6429de3d50e759afd71c355 d3631e3a67817637d690ba1d remember to do another pull before using the above command, because I merged the changes in master and removed the debug instructions from the code.
*** Bug 490732 has been marked as a duplicate of this bug. ***