Message-ID: <19021.17576.808138.476600@samba.org>
Date:	Fri, 3 Jul 2009 09:37:12 +1000
From:	tridge@...ba.org
To:	Jan Engelhardt <jengelh@...ozas.de>
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
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regression

Hi Jan,

 > 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.

Would you mind retesting again, but looking carefully at the VFAT
mount options. I don't think what you've described can happen without
differing VFAT options between your two examples.

I'll try and expain:

 > 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.

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

Now we would need to know what shortname= option was used here. If the
shortname= option was such that the lowercase name dscf3000.jpg was
considered as 8.3, then the patch I have posted would have had zero
effect on what was stored on disk. If it was not considered a short
name (because you have the shortname= option set to not allow
lowercase short names) then it would have been created as a long
name. As you said the file became invisible then I suspect that for
this test you had the shortname= option set to treat lowercase names
as not being allowed in 8.3.

 >  * 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.

ok, if 3001 was shown, then in this case you must have had different
VFAT mount options. I don't know if this is because the different base
kernel has different defaults, or if perhaps you used a different
system that had different mounting options.

If you had used the same mount options as the previous test, then the
3001 name could not have shown up I think. It would have shown up as
something like DSCF3~01.JPG. 

So I think all you've found is two things we already knew:

 1) VFAT mount options make for an easy trap to fall into :-)

 2) as the config text in the patch explains:

        "That means that long filenames created with this option
	 disabled will not be accessible at all to operating systems
	 that do not understand the VFAT extensions."

If you mount with the right shortname= options then I think you'll
find that your above test will work (for some value of work!)

But please do keep testing. We want to eliminate the possibility that
you have found a real example of where the patch causes a problem with
some embedded systems.

Cheers, Tridge
--
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/

Powered by blists - more mailing lists