Description of problem: `file` displays the wrong numbers to characterize a large squashfs file. Version-Release number of selected component (if applicable): file-5.38 How reproducible: Everytime Steps to Reproduce: 1. Create large squashfs file. E.g., curl https://tools.netsa.cert.org/silk/refdata/FCCX-pcap.tar.gz -O mkdir FCCX-pcap-mnt python -m ratarmount FCCX-pcap.tar.gz FCCX-pcap-mnt/ mksquashfs ./FCCX-pcap-mnt FCCX-pcap.squashfs -comp xz -b 1M -Xdict-size '100%' -noappend -info -progress 2. Use distro `file` to examine squashfs file $ file FCCX-pcap.squashfs FCCX-pcap.squashfs: Squashfs filesystem, little endian, version 1024.0, compressed, -8150485946417020928 bytes, 436207616 inodes, blocksize: 4096 bytes, created: Wed Mar 24 14:25:35 2083 3. Observe wacky numbers/date/etc. Actual results: See Step 2 above. Expected results: $ my_file FCCX-pcap.squashfs FCCX-pcap.squashfs: Squashfs filesystem, little endian, version 4.0, xz compressed, 5228782478 bytes, 26 inodes, blocksize: 1048576 bytes, created: Sun Oct 18 08:16:20 2020 Additional info: N.B.: `my_file` used above was built on the same system from HEAD of https://github.com/file/file (commit 516e713bd0d47a61305ac56e00bb76274b35856b) which is version 5.39, so perhaps just an update/recompile from current upstream will fix this issue.
FEDORA-2020-8897fb0f7b has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8897fb0f7b
I'm curious why only a single patch is applied when many patches and another release are available. Must a Fedora'er suffer each error to have existing patches applied?
We prefer not to rebase the `file` package in stable releases of Fedora because upstream does not use any continuous integration and upstream releases are known to accidentally introduce new bugs or backward-incompatible changes.
https://travis-ci.org/github/file/file/jobs/736909821#L440 `make -C test check` is inadequate? https://travis-ci.org/github/file/file/builds looks pretty busy. https://travis-ci.org/github/file/file/branches even version 5.39 seems to be in an inactive branch now.
FEDORA-2020-8897fb0f7b has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-8897fb0f7b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8897fb0f7b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
See the following examples of what may go wrong with `file` updates: bug #1367144 bug #1350252 bug #1296868 bug #1291903 bug #1279401 bug #1433364 bug #1515180 If you prefer to use unstable software, you are free to run a development version of Fedora.
(In reply to Kamil Dudka from comment #6) > See the following examples of what may go wrong with `file` updates: > > bug #1367144 > bug #1350252 > bug #1296868 > bug #1291903 > bug #1279401 > bug #1433364 > bug #1515180 Some of these bugs, like this one, were caused by **not** updating `file` as upstream fixed issues. Without reading all the details of all the bugs, the timelines of Fedora bug appearances versus upstream fixes isn't clear (though could be determined). > If you prefer to use unstable software, you are free to run a development > version of Fedora. Understood. It's clear there are risks when dependencies change. It would be interesting to see regression testing for all packages that depend on another package that proposes a change. Thanks for fixing this issue.
FEDORA-2020-8897fb0f7b has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.