mtools truncates short filenames in a way that can cause conflicts

Bug #481482 reported by Michael Casadevall on 2009-11-12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mtools (Ubuntu)

Bug Description

Binary package hint: mtools

On karmic and lucid, the newer version of mtools introduces a regression that causes filenames to break. According to the mtools documentation (, long filenames beyond eight characters should be truncated down to six characters then a tile and number. i.e. thisisatest becomes THISIS~1 for the short filename.

This behavior works correctly on 3.9 series mtools releases, but on 4.0, thisisatest would get truncated to thisisat. A simple testcase to this behavior is the following:

mcasadevall@daybreak:/tmp$ mkdosfs -C test.img 10000
mkdosfs 3.0.3 (18 May 2009)
mcasadevall@daybreak:/tmp$ mmd -i test.img libgnomecanvas
mcasadevall@daybreak:/tmp$ mmd -i test.img libgnome
Long file name "libgnome" already exists.
a)utorename A)utorename-all r)ename R)ename-all
s)kip S)kip-all q)uit (aArRsSq): q
mcasadevall@daybreak:/tmp$ mdir -i test.img
 Volume in drive : has no label
 Volume Serial Number is 952C-0A14
Directory for ::/

libgnome <DIR> 2009-11-12 13:52 libgnomecanvas
        1 file 0 bytes
                         10 199 040 bytes free

The attached debdiff corrects this behavior by having mtools properly truncate the short filename to libgno~1 in that case.

Related branches

Alexander Sack (asac) wrote :

yes. on hardy it works without a confirm ... so indeed a regression:

asac@tinya:~$ /sbin/mkdosfs -C test.img 10000
mkdosfs 2.11 (12 Mar 2005)
asac@tinya:~$ mmd -i test.img libgnomecanvas
asac@tinya:~$ mmd -i test.img libgnome

ii dosfstools 2.11-2.3ubuntu1 Utilities to create and check MS-DOS FAT filesystems

Changed in mtools (Ubuntu):
importance: Undecided → Critical
status: New → Triaged
Alexander Sack (asac) wrote :

err .... wrong package version pasted, here on hardy:
ii mtools 3.9.11-0ubuntu1 Tools for manipulating MSDOS files

Changed in mtools (Ubuntu):
importance: Critical → High
Alexander Sack (asac) wrote :

the reason why this is broken is that previously the mangling for long names was done when count reached zero in the TranslateToDos loop ... however, now the buffer is cut before the loop so the count is useless there ...

a cleaner approach than your patch would be to also deal with the !end case in native_to_wchar - which seems to do this already for end != 0 ...

Same patch should probably also drop the count business from the TranslateToDos loop.

Revised debdiff attached

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mtools - 4.0.10-1ubuntu1

mtools (4.0.10-1ubuntu1) lucid; urgency=low

  * Added debian/patches/11.truncation-fix.patch:
    - This corrects the behavior of name mangling and truncation when dealing
      with long filenames, and prevents possible conflicts between a shortname
      and a long filename. Thanks to Alexandar Sack for helping revise the patch
      (LP: #481482)
 -- Michael Casadevall <email address hidden> Thu, 12 Nov 2009 13:37:53 -0500

Changed in mtools (Ubuntu Lucid):
status: Triaged → Fix Released
Rolf Leggewie (r0lf) wrote :

Karmic has long since stopped to receive any updates. Marking the Karmic task for this ticket as "Won't Fix".

Changed in mtools (Ubuntu Karmic):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers