mtools truncates short filenames in a way that can cause conflicts
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
mtools (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Karmic |
Won't Fix
|
Undecided
|
Unassigned | ||
Lucid |
Fix Released
|
High
|
Unassigned |
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 (http://
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@
mkdosfs 3.0.3 (18 May 2009)
mcasadevall@
mcasadevall@
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@
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
The attached debdiff corrects this behavior by having mtools properly truncate the short filename to libgno~1 in that case.
yes. on hardy it works without a confirm ... so indeed a regression:
(hardy)
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