linux-kernel - Re: CONFIG_VFAT_FS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 3 Jul 2009 02:11:17 +0200 (CEST)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	tridge@...ba.org
cc:	Theodore Tso <tytso@....edu>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Pavel Machek <pavel@....cz>,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	john.lanza@...ux.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>, corbet@....net,
	jcm@...masters.org
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regression


On Friday 2009-07-03 01:37, tridge@...ba.org wrote:
>
> > Yes, here is your precedent case. The DUALNAMES patch breaks the
> > operation on my Fujifilm Finepix A210 digital camera.
>
>interesting, but I think you may have been trapped by differences in
>the VFAT mounting options between the two examples.

No special options — all defaults to whatever the Linux kernel and
util-linux 2.14.1 gave me. Whereby util-linux should not make a
difference because it just passes on the mount request for there is
no special vfat helper.

Given my second report about the audio player (just sent out), I even
compared dualnames=n with =y on the same kernel — which would rule
out changed defaults between 2.6.29 and 2.6.31-rc.

/proc/mounts contains, on .31-rc:

/dev/sdc1 /mnt vfat rw,relatime,fmask=0022,dmask=0022,codepage=437
iocharset=utf8,errors=remont-ro 0 0

> > Here, dscf4159.jpg is a preexisting file created by the camera itself 
> > (and subsequently, Finepix's FAT code) as a result of taking a picture. 
> > Then I just copied that file with two different kernels in succession.
>
>ok, dscf4159.jpg may or may not be a 8.3 name depending on the
>"shortname=" mount option. As this is a digital camera, I suspect that
>it was created as an 8.3 name, although you'd have to confirm that by
>inspecting the disk image. If you made a copy of the image available
>to me somewhere (please don't email it unless it compresses to a small
>size!) then I can tell you what the camera did in this case.

http://jengelh.medozas.de/files/finepix.img.bz2
(Includes an unreadable dscf3000 entry.)

Then, I just tried everything to get an overview:

 (All with DUALNAMES=n)
 # mount /dev/sdc1 /mnt -o iocharset=utf8,shortnames=lower
 # cp /mnt/dcim/100_fuji/dscf{4160,3004}.jpg
 # umount /mnt
 # mount /dev/sdc1 /mnt -o iocharset=utf8,shortnames=win95
 # cp /mnt/dcim/100_fuji/dscf{4160,3005}.jpg
 # umount /mnt
 # mount /dev/sdc1 /mnt -o iocharset=utf8,shortnames=winnt
 # cp /mnt/dcim/100_fuji/dscf{4160,3006}.jpg
 # umount /mnt
 # mount /dev/sdc1 /mnt -o iocharset=utf8,shortnames=mixed
 # cp /mnt/dcim/100_fuji/dscf{4160,3007}.jpg
 # umount /mnt

Result? The camera only displays 3006.

The dualnames patch's filling filenames with random illegal
chars does seems to have a really foul side-effect after all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/