FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-12-2008, 12:19 AM
Frank Lichtenheld
 
Default Kernel 2.6.25 broke iPod support for me, but who to bug?

Hi.

While testing some updates to my gtkpod/libgpod packages I noticed that
I couldn't actually play any songs anymore from my iPod. Which worked
fine some weeks ago.

I traced the error back to a change in kernel 2.6.25: Apparently vfat
file system can now become case sensitive in some cases
("FAT: utf8 is not a recommended IO charset for FAT filesystems,
filesystem will be case sensitive!") which the mentioned applications
are totally not prepared for. They try to access files with their name
in upper case, but since the default for vfat is "shortname=lower" this
doesn't actually work anymore for files and directories that have no
long name saved on the file system.

So my question now is where to file the bug and I would be grateful
for recommendations:

- kernel: I find it unlikely that the mentioned change was done without
a good reason given its obvious behavioural change. So I guess the
chances that it can be reversed are slim. But I might be wrong?
- hal/util-linux: Maybe it would be a good idea to mount case sensitive
vfat filesystems with shortname=winnt in the hope that would disturb
fewer users. It would have fixed the problem at least in my case,
but I'm not so sure it would be the right solution for most cases?
- applications (libgpod in this case): The application could try to
normalize the filename to lower case if it knows that it handles data
on a file system that could cause problems like this. But that sounds
like a awful lot of special casing to me.

Any ideas?
Any other examples of applications broken by this change?

Gruesse,
--
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-12-2008, 01:11 AM
James Vega
 
Default Kernel 2.6.25 broke iPod support for me, but who to bug?

On Sat, Jul 12, 2008 at 02:19:58AM +0200, Frank Lichtenheld wrote:
> Hi.
>
> While testing some updates to my gtkpod/libgpod packages I noticed that
> I couldn't actually play any songs anymore from my iPod. Which worked
> fine some weeks ago.
>
> I traced the error back to a change in kernel 2.6.25: Apparently vfat
> file system can now become case sensitive in some cases
> ("FAT: utf8 is not a recommended IO charset for FAT filesystems,
> filesystem will be case sensitive!")

Are you sure this is a kernel change and not just a change in your
kernel config? I brought up what seems to be the same (or at least
closely related) problem 4 years ago on lkml[0].

[0] - http://lkml.org/lkml/2004/4/5/209
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
 
Old 07-12-2008, 01:20 AM
Frank Lichtenheld
 
Default Kernel 2.6.25 broke iPod support for me, but who to bug?

On Fri, Jul 11, 2008 at 09:11:57PM -0400, James Vega wrote:
> On Sat, Jul 12, 2008 at 02:19:58AM +0200, Frank Lichtenheld wrote:
> > Hi.
> >
> > While testing some updates to my gtkpod/libgpod packages I noticed that
> > I couldn't actually play any songs anymore from my iPod. Which worked
> > fine some weeks ago.
> >
> > I traced the error back to a change in kernel 2.6.25: Apparently vfat
> > file system can now become case sensitive in some cases
> > ("FAT: utf8 is not a recommended IO charset for FAT filesystems,
> > filesystem will be case sensitive!")
>
> Are you sure this is a kernel change and not just a change in your
> kernel config? I brought up what seems to be the same (or at least
> closely related) problem 4 years ago on lkml[0].

To be precise the upgrade from the current (i.e. today) 2.6.24 testing
kernel to the current 2.6.25 unstable kernel causes the problem.

So yeah, both code and config changed I guess.

Gruesse,
--
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-12-2008, 02:08 AM
Steve Langasek
 
Default Kernel 2.6.25 broke iPod support for me, but who to bug?

On Sat, Jul 12, 2008 at 02:19:58AM +0200, Frank Lichtenheld wrote:

> While testing some updates to my gtkpod/libgpod packages I noticed that
> I couldn't actually play any songs anymore from my iPod. Which worked
> fine some weeks ago.

> I traced the error back to a change in kernel 2.6.25: Apparently vfat
> file system can now become case sensitive in some cases
> ("FAT: utf8 is not a recommended IO charset for FAT filesystems,
> filesystem will be case sensitive!") which the mentioned applications
> are totally not prepared for. They try to access files with their name
> in upper case, but since the default for vfat is "shortname=lower" this
> doesn't actually work anymore for files and directories that have no
> long name saved on the file system.

vfat has never supported case-insensitivity when using utf8. You have to
pick either case-insensitivity, or unicode. If the kernel has changed the
behavior of vfat when using iocharset=utf8, this merely makes the problems
more explicit; it was already broken in various subtle ways before this.

> So my question now is where to file the bug and I would be grateful
> for recommendations:

> - kernel: I find it unlikely that the mentioned change was done without
> a good reason given its obvious behavioural change. So I guess the
> chances that it can be reversed are slim. But I might be wrong?

I don't think this will do any good. As James mentions, there have been
known problems with vfat+utf8 for years, that have gone unaddressed; I don't
think one more bug report will change things.

> - hal/util-linux: Maybe it would be a good idea to mount case sensitive
> vfat filesystems with shortname=winnt in the hope that would disturb
> fewer users. It would have fixed the problem at least in my case,
> but I'm not so sure it would be the right solution for most cases?

I don't think there's any way to detect at mount time whether a filesystem
*is* case-sensitive or not; if shortname=winnt will work around this
behavior, then we should instead probably use this as a default any time
utf8 is being used as the iocharset.

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-14-2008, 05:27 PM
Teemu Likonen
 
Default Kernel 2.6.25 broke iPod support for me, but who to bug?

Frank Lichtenheld wrote:

> I traced the error back to a change in kernel 2.6.25: Apparently vfat
> file system can now become case sensitive in some cases
> ("FAT: utf8 is not a recommended IO charset for FAT filesystems,
> filesystem will be case sensitive!")

> - kernel: I find it unlikely that the mentioned change was done without
> a good reason given its obvious behavioural change. So I guess the
> chances that it can be reversed are slim. But I might be wrong?

I have described one aspect of this issue in the bug report #417324:

"linux-2.6: UTF-8 is the system-wide default encoding in Debian but
kernel's filesystem modules use ISO-8859-1"

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=417324

In short: VFAT filesystem stores long filenames _always_ in UTF-16.
Since Debian doesn't use UTF-16, filename strings must always be
converted to some other encoding (and that's the option we give to mount
or to kernel at compile time). Debian's default is UTF-8 so the obvious
default for kernel's filesystem modules is also UTF-8. As you noticed,
the change was introduced in the Debian kernel 2.6.25.

There have been serious filename issues before the change. By default
Debian Etch (excluding KDE) writes complete garbage to VFAT filenames
(only ASCII characters work). Etch also interprets beyond-ASCII
filenames in VFAT wrong if they were written by a correctly configured
system (MS Windows, for example). I described the conversion problems in
#417324.

BTW, I'm using shortname=mixed succesfully here.

(I'm not a subscriber to -devel, so please Cc me, thanks.)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 02:51 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org