File Commander doesn't detect failure to unpack because of missing archive program

If an archive program is missing (other than rar, which has other issues, see bug ~~#693~~), when File Commander is asked to unpack an archive, it will report that the archive was successfully unpacked, even though that is impossible.

This is an additional issue to bug ~~#694~~ where the archive program's exit status is ignored.

In this case, bidirpipe() in lib/base/console.cpp exits in the child process from the fork with status 0 if execvp() returns (and on all other error conditions). execvp() only returns in the process if it fails. On its return, and for all other _exit() calls from bidirpipe() the exit() should return non-zero.

Also in bidirpipe(), if execvp() returns, it prints "[eConsoleAppContainer] Finished command", even though the command couldn't even be started. The "command finished" message needs to be printed in eConsoleAppContainer::readyRead() after the call to waitpid(). In that position it can also use the child process's exit status to report whether the child process reported failure through a non-zero exit, or whether the child was killed by a signal.

The handling of the child process's exit status in eConsoleAppContainer::readyRead() is also incorrect.

It passes -1 as the appClosed message parameter if the child was killed by eConsoleAppContainer::kill(), but if the child is killed by any other signal, including SIGINT sent by eConsoleAppContainer::sendCtrlC() it will send 0 (no error) as the appClosed message parameter.

It would be better to also test for WIFSIGNALED(childstatus), and pass -WTERMSIG(childstatus) as the message parameter if the child was killed by any signal.

That would provide more, and more accurate, information to users of the class.

There isn't a simple way to replicate this bug other than by code examination, because it is effectively masked by bug ~~#694~~ where the child process's exit status is ignored anyway.

Comments (2)