Anton Altaparmakov <[EMAIL PROTECTED]> writes:
>> Probably, yes. I think we need to know on-disk filename's code set.
>
> If FAT stores the filenames in 8 bits (non-UTF) then yes, it will be in
> the current locale/code page of the Windows system writing them (e.g. that
> happens with the names
On Sun, 30 Oct 2005, OGAWA Hirofumi wrote:
> Ingo Oeser <[EMAIL PROTECTED]> writes:
> >> This is known bug. For fixing this bug cleanly, we will need to much
> >> change the both of nls and filesystems.
> >
> > Using per locale collation sequences? :-)
> >
> > Do you know, how Windows handles the p
Ingo Oeser <[EMAIL PROTECTED]> writes:
>> This is known bug. For fixing this bug cleanly, we will need to much
>> change the both of nls and filesystems.
>
> Using per locale collation sequences? :-)
>
> Do you know, how Windows handles the problem of differing collation
> sequences on the file s
Hi,
On Friday 28 October 2005 16:54, OGAWA Hirofumi wrote:
> Horms <[EMAIL PROTECTED]> writes:
> > I guess it is charset2lower or charset2upper that vfat is calling,
> > which make no conversion, thus leading to the problem I outlined above.
> >
> > My question is: Is this behaviour correct, or is
On Fri, Oct 28, 2005 at 12:40:38PM +0200, Bastian Blank wrote:
> tags 333776 upstream
> thanks
>
> On Fri, Oct 14, 2005 at 05:35:49PM -0700, Steve Langasek wrote:
> > Ok, I can confirm that this is not reproducible using your above test case.
> > The missing variable appears to be that I am mounti
On Sat, Oct 29, 2005 at 12:07:40AM +0900, OGAWA Hirofumi wrote:
> OGAWA Hirofumi <[EMAIL PROTECTED]> writes:
>
> > Horms <[EMAIL PROTECTED]> writes:
> >
> >> static struct nls_table table = {
> >> .charset= "utf8",
> >> .uni2char = uni2char,
> >> .char2uni
OGAWA Hirofumi <[EMAIL PROTECTED]> writes:
> Horms <[EMAIL PROTECTED]> writes:
>
>> static struct nls_table table = {
>> .charset= "utf8",
>> .uni2char = uni2char,
>> .char2uni = char2uni,
>> .charset2lower = identity, /* no conversion */
>>
Horms <[EMAIL PROTECTED]> writes:
> static struct nls_table table = {
> .charset= "utf8",
> .uni2char = uni2char,
> .char2uni = char2uni,
> .charset2lower = identity, /* no conversion */
> .charset2upper = identity,
> .owner
tags 333776 upstream
thanks
On Fri, Oct 14, 2005 at 05:35:49PM -0700, Steve Langasek wrote:
> Ok, I can confirm that this is not reproducible using your above test case.
> The missing variable appears to be that I am mounting my partition using
> -oiocharset=utf8. If I use -oisocharset=iso8859-1
Ogawa-san,
I'm bringing this to you attention because a) I'm not sure who to ask
and b) I'm not sure what the correct behaviour is.
When a vfat filesystem is mounted isocharset=iso8859-1, then the
following works:
touch a.txt
ls A.txt
But when it is mounted isocharset=utf8, then ls complains, f
On Fri, Oct 14, 2005 at 05:35:49PM -0700, Steve Langasek wrote:
[snip]
> Ok, I can confirm that this is not reproducible using your above test case.
> The missing variable appears to be that I am mounting my partition using
> -oiocharset=utf8. If I use -oisocharset=iso8859-1 (the default), the m
tags 333776 -unreproducible moreinfo
thanks
Hi Horms,
On Fri, Oct 14, 2005 at 11:32:18AM +0900, Horms wrote:
> Unfortunately I am unable to reproduce this problem with current sid
> using linux-image-2.6.12-1-686-smp 2.6.12-10
> I created a partition using:
> $ dd bs=1024 count=1024 if=/dev/zer
tag 333776 +unreproducible
tag 333776 +moreinfo
thanks
On Thu, Oct 13, 2005 at 09:55:29AM -0700, Steve Langasek wrote:
> Package: linux-2.6
> Version: 2.6.12-6
>
> The vfat driver in 2.6.12 appears to include a regression compared with
> earlier versions. VFAT is a case-insensitive filesystem, b
Package: linux-2.6
Version: 2.6.12-6
The vfat driver in 2.6.12 appears to include a regression compared with
earlier versions. VFAT is a case-insensitive filesystem, but with this
kernel filenames are not handled in a case-insensitive manner:
$ cd /media/usb0/
$ touch foo
$ ls -l foo
-rw---
14 matches
Mail list logo
