Package: file Followup-For: Bug #1040467 Indeed if I only read 4096 bytes, I get: 1+0 records in 1+0 records out 4096 bytes (4.1 kB, 4.0 KiB) copied, 5.5761e-05 s, 73.5 MB/s /dev/stdin: data
If I read the entire file size, except for the last byte, I still get: $ dd if=/tmp/image bs=$(( $(stat --format=%s /tmp/image) - 1)) count=1 | file - 1+0 records in 1+0 records out 565109 bytes (565 kB, 552 KiB) copied, 0.00157071 s, 360 MB/s /dev/stdin: data Only when I read the whole file, then I get: $ dd if=/tmp/image bs=$(stat --format=%s /tmp/image) count=1 | file - 1+0 records in 1+0 records out 565110 bytes (565 kB, 552 KiB) copied, 0.00156589 s, 361 MB/s /dev/stdin: PC bitmap, Windows 3.x format, 434 x 432 x 24, image size 565056, cbSize 565110, bits offset 54 So it appears the very last byte is still important for correct detection of the image file through `file` and 4096 bytes will never be enough in this case. For unknown reasons, this workaround does not work, because nbytes=4096 is still being used: $ </sys/firmware/acpi/bgrt/image file - /dev/stdin: data But if I do "useless use of cat", then nbytes=565110 is used and it works: $ cat /sys/firmware/acpi/bgrt/image | file - /dev/stdin: PC bitmap, Windows 3.x format, 434 x 432 x 24, image size 565056, cbSize 565110, bits offset 54 So `file` still performs some special behavior when it detects that stdin comes from /sys