Oh dear. As I read all the stuff about 2.6.32 changing long filename
handling for VFAT filesystems to avoid Microsoft patent problems, I
didn't think it mattered much to me, since I only use FAT when getting
pictures from a camera or USB stick. Now I find that filenames are
all upper case where they weren't before.
I see a bunch of mount options to use lower case filenames, but what I
would really like to do is restore the old behavior, whatever it was,
with a 2.6.32 kernel. Is there such an option, either building a
kernel or mounting a filesystem?
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
01-08-2010, 03:13 PM
Xavier Parizet
2.6.32 and FAT file names
Le 08/01/2010 17:09, felix@crowfix.com a écrit :
> Oh dear. As I read all the stuff about 2.6.32 changing long filename
> handling for VFAT filesystems to avoid Microsoft patent problems, I
> didn't think it mattered much to me, since I only use FAT when getting
> pictures from a camera or USB stick. Now I find that filenames are
> all upper case where they weren't before.
>
> I see a bunch of mount options to use lower case filenames, but what I
> would really like to do is restore the old behavior, whatever it was,
> with a 2.6.32 kernel. Is there such an option, either building a
> kernel or mounting a filesystem?
For me, plugin-in a FAT formatted usb-key on my system implied mounting it using
hal, which implies mount options
(rw,nosuid,nodev,noatime,uhelper=hal,shortname=low er,flush,uid=1000) using vfat.
On Fri, Jan 8, 2010 at 10:09 AM, <felix@crowfix.com> wrote:
> Oh dear. As I read all the stuff about 2.6.32 changing long filename
> handling for VFAT filesystems to avoid Microsoft patent problems, I
> didn't think it mattered much to me, since I only use FAT when getting
> pictures from a camera or USB stick. Now I find that filenames are
> all upper case where they weren't before.
>
> I see a bunch of mount options to use lower case filenames, but what I
> would really like to do is restore the old behavior, whatever it was,
> with a 2.6.32 kernel. Is there such an option, either building a
> kernel or mounting a filesystem?
I haven't noticed any difference with any of my vfat devices in
2.6.32. Filenames have mixed-case and seem usual. Where did you read
about 2.6.32 changing long filename handling? I can't find any info
about it.
01-08-2010, 08:39 PM
2.6.32 and FAT file names
On Fri, Jan 08, 2010 at 02:01:08PM -0600, Paul Hartman wrote:
> I haven't noticed any difference with any of my vfat devices in
> 2.6.32. Filenames have mixed-case and seem usual. Where did you read
> about 2.6.32 changing long filename handling? I can't find any info
> about it.
I have read it in several places, but the only one I (think I)
remember by name is lwn.net, and I couldn't give you any specific
article.
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
01-08-2010, 10:17 PM
Paul Hartman
2.6.32 and FAT file names
On Fri, Jan 8, 2010 at 3:39 PM, <felix@crowfix.com> wrote:
> On Fri, Jan 08, 2010 at 02:01:08PM -0600, Paul Hartman wrote:
>
>> I haven't noticed any difference with any of my vfat devices in
>> 2.6.32. Filenames have mixed-case and seem usual. Where did you read
>> about 2.6.32 changing long filename handling? I can't find any info
>> about it.
>
> I have read it in several places, but the only one I (think I)
> remember by name is lwn.net, and I couldn't give you any specific
> article.
In the 2.6.32 kernel ChangeLog this is the only thing that looks to
address it, and if anything it sounds like it should be the opposite
of your problem (fixing it instead of causing it)... weird. Maybe try
to add shortname=mixed to your mount options in case something in your
system has it set otherwise.
commit 955234755ce4a2c33cfc558912aa8f2148cc1fc6
Author: Paul Wise <pabs3@bonedaddy.net>
Date: Sat Aug 1 21:30:31 2009 +0900
vfat: change the default from shortname=lower to shortname=mixed
Because, with "shortname=lower", copying one FAT filesystem tree to
another FAT filesystem tree using Linux results in semantically
different filesystems. (E.g.: Filenames which were once "all
uppercase" are now "all lowercase").
So, this changes the default of "shortname=lower" to "shortname=mixed".
Signed-off-by: Paul Wise <pabs3@bonedaddy.net>
[change fat_show_options()]
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
01-09-2010, 03:36 AM
2.6.32 and FAT file names
On Fri, Jan 08, 2010 at 05:17:44PM -0600, Paul Hartman wrote:
> In the 2.6.32 kernel ChangeLog this is the only thing that looks to
> address it, and if anything it sounds like it should be the opposite
> of your problem (fixing it instead of causing it)... weird. Maybe try
> to add shortname=mixed to your mount options in case something in your
> system has it set otherwise.
>
> commit 955234755ce4a2c33cfc558912aa8f2148cc1fc6
> Author: Paul Wise <pabs3@bonedaddy.net>
> Date: Sat Aug 1 21:30:31 2009 +0900
>
> vfat: change the default from shortname=lower to shortname=mixed
No, that just might explain it. I'll reboot tomorrow under 2.6.31 and
if the problem persists, then it is probably something like udev or
who knows what. But if it was mounted as "lower" and now "mixed",
that would explain why I see the change. I remember the DOS systems
always being upper case, so the "lower" default would have lowered
them to what I was used to seeing, while the new "mixed" would have
preserved their teletypeness that I now see.
I looked quickly on lwn back thru Oct 1 and found nothing similar to
what I remember, so I will quit searching. There was some kerfuffle
about crippling some feature under some circumstances, trying to make
VFAT do 99%f off what it should but not 100%, so it couldn't be claimed
as a patent violation. There was some mention of this being related
to TomTom settling a patent lawsuit with Microsoft. I think the
change note you found is more likely the cause, and I will report
tomorrow on this.
Thanks for looking for this, BTW. I didn't think it was worth being
that ambitious :-)
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o