Re: CONFIG_VFAT_FS_DUALNAMES regression

[Jan Engelhardt]

On Wednesday 2009-07-01 16:05, Theodore Tso wrote:
>On Wed, Jul 01, 2009 at 12:25:58PM +0100, Alan Cox wrote:
>
>> (most *FAT using products don't use Microsofts
>> implementation). Testing it versus Windows and saying it works is
>> not really adequate. Thats what ACPI and BIOS people do that *we*
>> moan about all the time.
>
>[...]
>The other big user I can think of are digital cameras, but (a)
>normally most users read from them and then delete the pictures, and
>rarely write to media meant for a digital camera, and (b) the DCIM
>standard for digital cameras explicitly only supports 8.3 filenames
>and so digital camera manufacturers explicitly don't need to deal with
>Long File Names at all.  (Hmm.... I wonder why....)
>[...]
>Ultimately, though, requiring that every single possible device be
>tested is probably not reasonable, so the best way to do this testing
>is the way do most of our testing; we do basic due diligence, but then
>we merge it into mainline and let our huge user community try it out.


Yes, here is your precedent case. The DUALNAMES patch breaks the
operation on my Fujifilm Finepix A210 digital camera.

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.

 * 2.6.31-rc1 + dualnames=n
   # mount /dev/sdc1 /mnt
   # cd /mnt/dcim/100_fuji/; cp dscf4159.jpg dscf3000.jpg
   # umount /mnt

 * 2.6.29.5 w/o patch
   # same procedure
   cp dscf4159.jpg dscf3001.jpg

End result is that picture ID 3000 is not selectable in the camera's
built-in menu (OSD), as if the file did not exist. 3001 was shown,
however.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/