Bug#990486: mtools: mcopy -b crashes with "Internal error, size too big"

[Göran Weinholt]

Package: mtools
Version: 4.0.31-1
Severity: minor

I have a script that uses mtools to create a FAT partition and it has
stopped working with recent mtools versions:


+ dd if=/dev/zero of=img.tmp bs=512 count=100031
100031+0 records in
100031+0 records out
51215872 bytes (51 MB, 49 MiB) copied, 0,0473954 s, 1,1 GB/s
+ mformat -i img.tmp
+ mcopy -i img.tmp -sb /usr/share/common-licenses ::
Internal error, size too big
Streamcache allocation problem:: 4


This worked with 4.0.26-1 (currently in testing). It also works
without the -b flag. The -b flag is described as an optimization, so a
simple workaround for anyone affected is to stop using -b.


-- System Information:
Debian Release: 11.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel

Kernel: Linux 5.10.0-7-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_DK.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mtools depends on:
ii libc6 2.31-12

mtools recommends no packages.

Versions of packages mtools suggests:
pn floppyd <none>

-- Configuration Files:
/etc/mtools.conf changed:
drive a: file="/dev/fd0" exclusive
drive b: file="/dev/disk/by-id/usb-MITSUMI0_MITSUMI0" exclusive
drive m: file="/var/lib/dosemu/hdimage.first" partition=1 offset=128
drive n: file="/var/lib/dosemu/fdimage"


-- no debconf information

[Chris Lamb]

Hi Göran,

> I have a script that uses mtools to create a FAT partition and it has
> stopped working with recent mtools versions:
>

[..]

> This worked with 4.0.26-1 (currently in testing). It also works
> without the -b flag. The -b flag is described as an optimization, so a
> simple workaround for anyone affected is to stop using -b.

Thank for the bug report. Are you able to report this upstream via
their mailing list? I can do this myself, but it might more sense for
you to do so just in case they have any followups. I believe you can
signup and post by following these instructions:

https://www.gnu.org/software/mtools/#mailing


Regards,

--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org 🍥 chris-lamb.co.uk
`-

[Silvio Knizek]

Hi,

so I use [simplediskimage](https://pypi.org/project/simplediskimage/), a python wrapper for several tools (including `mtools`) to build a simple disk image.

When I run my script inside the official 3.11-bookworm container from hub.docker.io, `mcopy -i <redacted tmp file> -bQ <source file> <target file>` fails with

```

Internal error, size too big

Streamcache allocation problem:: 3
```

This does not happen with the 3.11-bullseye container with `mtools` 4.0.26. According to [the internet](https://github.com/PartialVolume/shredos.x86_64/issues/120) this is fixed as well in 4.0.42.

As I can't change the way `simplediskimage` is calling `mcopy` and remove the `-b` option, I would like to have the fix (whatever it is) back ported.

BR
Silvio

[Trent W. Buck]

Silvio,

Thanks, changing "mcopy -b" to "mcopy" fixed things for me.

For the record, I attach the full scripts;
Debian 12 (4.0.33-1+really4.0.32-1) fails with -b;
Debian 11 (mtools=4.0.26-1) works with -b.