Date: Sun, 29 Apr 2018 18:45:40 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 111843] [msdosfs] Long Names of files are incorrectly created on msdosfs Message-ID: <bug-111843-227-fNgkYufKPi@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-111843-227@https.bugs.freebsd.org/bugzilla/> References: <bug-111843-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D111843 Damjan Jovanovic <damjan.jov@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov@gmail.com --- Comment #3 from Damjan Jovanovic <damjan.jov@gmail.com> --- Still happens on CURRENT. Can be reproduced with any file where, for an integer N > 0, the filename begins with 13*N valid characters, the last of those not being a space or d= ot, and extra spaces and/or dots follow those characters. For example: $ touch "1234567890123 " $ ls 123456~1 Why? In sys/fs/msdosfs/msdosfs_lookup.c, ddep->de_fndcnt gets set in the msdosfs_lookup_() function, and it's supposed to count the number of LFN entries we will need to store the long filename. This is obtained from winSlotCnt() which trims trailing spaces and dots with winLenFixup(), and divides the resulting length by WIN_CHARS (13), which is the maximum number= of chars in an LFN entry. createde() in sys/fs/msdosfs/msdosfs_lookup.c generates the long file name = from this, by calling unix2winfn() ddep->de_fndcnt times, each one generating one LFN entry for that consecutive non-overlapping 13 character substring of the long filename. The bug is in this unix2winfn() function in sys/fs/msdosfs/msdosfs_conv.c. = The function trims trailing spaces and/or dots, and then tries to write up to 1= 3 of the remaining characters into the LFN entry. The last LFN entry must have WIN_LAST (0x40) OR-ed into its sequence number. If the filename ends before= all 13 characters are populated, WIN_LAST is set. But if the filename is an exa= ct multiple of 13 characters, the code relies on the original string to termin= ate in "\0" in order to set WIN_LAST: if (*un =3D=3D '\0') end =3D WIN_LAST; The problem is that if the string ends in spaces and/or dots, it doesn't en= d in "\0" yet, so that test fails and WIN_LAST isn't set, producing a corrupt lo= ng filename. With the long filename corrupted, "ls" only shows the short name. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-111843-227-fNgkYufKPi>