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.

Hi Göran,
[..]

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,

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

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.