mksquashfs/unsquashfs: fix mtime signedness

Since time-immemorial Squashfs has treated mtime as unsigned.
This is a bug, mtime is signed, and dates previous to the
epoch of 1 Jan 1970 should be treated negatively.

This bug does not affect mksquashfs, as it stores the mtime
in the filesystem correctly.  Unsquashfs, however, treats
mtime as unsigned, and it will report (-lls) and
set any file with a timestamp before the epoch incorrectly.

This is easily fixed by changing the definition of mtime
(and mkfs_time) to be "int" rather than "unsigned int".
Because the signedness is changing, the swap code also
has to be undated.

Reported-by: socketpair@gmail.com
Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
unsquashfs: fix mtime signedness for legacy layouts

Since time-immemorial Squashfs has treated mtime as unsigned.
This is a bug, mtime is signed, and dates previous to the
epoch of 1 Jan 1970 should be treated negatively.

This bug has never affected Mksquashfs, and so there is a small but
unlikely possibility that there can exist legacy Squashfs filesystems
with timestamps prior to the epoch.

Due to this, This commit fixes mtime signedness for the legacy
1.x, 2.x and 3.x layouts, so negative mtime is correctly handled by
Unsquashfs.

Note the legacy swapping code does not have to be updated
because it never interprets signedness of the data.

signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
mksquashfs: simplify print_filename in info.c

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
mksquashfs: fix progress bar enabling/disabling

Previously I rewrote the progress bar to introduce temporary disabling
and enabling for the info thread (when it is displaying the cache/queue
status the progress bar needs to be disabled).

This commit unfortunately didn't go far enough, it left
the situation where:

1. mksquashfs at start-up enabled the overall progress bar enable
   flag (but didn't turn it on)
2. Used the call "enable_progress_bar" to turn on the progress bar, and
3. Used the call "disable_progress_bar" to disable the progress bar once
   compression had been done (prior to generating the statistics dump
   and exiting).

This was a significant improvement in that hitting ^\ twice no
longer resulted in the progress bar being enabled even if it had been
explicitly disabled on the command line, but, it has been noticed (by me)
that there were still some weird cases:

1. Hitting ^\ twice to display the cache/queue status *before* the
   progress bar was turned on by mksquashfs would prematurely enable
   the progress bar.
2. Hitting ^\ twice to display the cache/queue status *after* the
   progress bar was turned off by mksquashfs would turn the progress
   bar back on.

The reasons for this should be readily apparent:

In case 1. the enable_progress_bar() called by the info
thread to re-enable the progress bar would prematurely enable it.

In case 2. the enable_progress_bar() called by the info
thread to re-enable the progress bar would unwantedly re-enable it.

The solution of course is that the main mksquashfs thread should
never have been using the temporary calls to "hard" enable and
disable the progress bar when it wanted to turn on and turn off
the progress bar.   So update set_progressbar_state() to do the "hard"
enabling/disabling when the main mksquashfs thread wants to do it.

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
progressbar: set_progressbar_state() can be called by threads killed

when restoring the filesystem, due to this we must ensure
the mutex is cleanly released.

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>