[9fans] FAT32 question

[9fans] FAT32 question

[Comeau At9Fans]

I'm mounting a FAT32 flashdrive on a RPi.  However, it seems that some
sort of legacy 8.3 filename situation is existing.  For instance, if I
have a directory containing x.c and a23456789.c that the former is
taken as X.C and the latter is taken as shown.  Therefore, to compile
x.c is not possible.  So for instance, echo *.c produces a different
result than echo *.C.  I tried mv'ing the problem files and then back
but same results.

I do believe that historically there was some sort of interpretations
such as this in the evolution from FAT to FAT32, but not sure it
should be so in current version, or, at least, other operating systems
don't take this interpretation.  Is there an option or something I'm
missing?  How do I get to process x.c as x.c and not X.C.

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] FAT32 question

[erik quanstrom]

On Wed Mar 27 08:26:04 EDT 2013, comeauat9fans@gmail.com wrote:
> I'm mounting a FAT32 flashdrive on a RPi.  However, it seems that some
> sort of legacy 8.3 filename situation is existing.  For instance, if I
> have a directory containing x.c and a23456789.c that the former is
> taken as X.C and the latter is taken as shown.  Therefore, to compile
> x.c is not possible.  So for instance, echo *.c produces a different
> result than echo *.C.  I tried mv'ing the problem files and then back
> but same results.

modulo other bugs, dossrv does something kind of interesting.
if you explictly walk to x.c, you will have a match.  but it doesn't
do this when stating a directory.  so if the file lists as "x.c" you
should be able to compile it.

ladd# cd /n/9fat
ladd# lc
9LOAD		9PCCPU.GZ	9pccpu		PLAN9.INI
ladd# cat plan9.ini>/dev/null
lladd# cat PLAN9.ini>/dev/null
ladd# cat PLAN9.INI>/dev/null

see /sys/src/cmd/dossrv/dossubs.c:/^mkalias for dossrv's
8.3 tricks.

- erik

Re: [9fans] FAT32 question

[Comeau At9Fans]

On Wed, Mar 27, 2013 at 8:33 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Wed Mar 27 08:26:04 EDT 2013, comeauat9fans@gmail.com wrote:
>>...  I tried mv'ing the problem files and then back
>> but same results.
>
> modulo other bugs, dossrv does something kind of interesting.
> if you explictly walk to x.c, you will have a match.  but it doesn't
> do this when stating a directory.  so if the file lists as "x.c" you
> should be able to compile it.
>
> ladd# cd /n/9fat
> ladd# lc
> 9LOAD           9PCCPU.GZ       9pccpu          PLAN9.INI
> ladd# cat plan9.ini>/dev/null
> lladd# cat PLAN9.ini>/dev/null
> ladd# cat PLAN9.INI>/dev/null

That seems correct from what I saw.  The problem is in globing though,
*.c will yield differently than x.c/X.c/x.C/X.C.  Anyway, I seem to be
past this part of things as I just tried mv'ing on Plan 9 itself
rather than the host system and that seems to be letting x.c be seen
as itself, or whatever it is that's going on or not is good enough for
me now.

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] FAT32 question

[Nicolas Bercher]

On 27/03/2013 15:18, Comeau At9Fans wrote:
> On Wed, Mar 27, 2013 at 8:33 AM, erik quanstrom<quanstro@quanstro.net>  wrote:
>> On Wed Mar 27 08:26:04 EDT 2013, comeauat9fans@gmail.com wrote:
>>> ...  I tried mv'ing the problem files and then back
>>> but same results.
>>
>> modulo other bugs, dossrv does something kind of interesting.
>> if you explictly walk to x.c, you will have a match.  but it doesn't
>> do this when stating a directory.  so if the file lists as "x.c" you
>> should be able to compile it.
>>
>> ladd# cd /n/9fat
>> ladd# lc
>> 9LOAD           9PCCPU.GZ       9pccpu          PLAN9.INI
>> ladd# cat plan9.ini>/dev/null
>> lladd# cat PLAN9.ini>/dev/null
>> ladd# cat PLAN9.INI>/dev/null
>
> That seems correct from what I saw.  The problem is in globing though,
> *.c will yield differently than x.c/X.c/x.C/X.C.  Anyway, I seem to be
> past this part of things as I just tried mv'ing on Plan 9 itself
> rather than the host system and that seems to be letting x.c be seen
> as itself, or whatever it is that's going on or not is good enough for
> me now.

Maybe a solution would be do to this in two passes.  Since x.c and X.C
describe the same file, it is not possible to rename it directly:

   cpu% touch X.C
   cpu% mv X.C x.c
   mv: X.C and ./x.c are the same

Just try something like this:

   cpu% mv X.C _x.c
   cpu% mv _x.c x.c
   cpu% ls *.c
   x.c
   cpu%

It worked for me on the 9fat partition (the only difference being
my Plan9 runs on an Atom, not a RPi).

Nicolas

Re: [9fans] FAT32 question

[Comeau At9Fans]

On Wed, Mar 27, 2013 at 12:02 PM, Nicolas Bercher <nbercher@yahoo.fr> wrote:
> On 27/03/2013 15:18, Comeau At9Fans wrote:
>>... I seem to be
>> past this part of things as I just tried mv'ing on Plan 9 itself
>> rather than the host system and that seems to be letting x.c be seen
>> as itself...
> Maybe a solution would be do to this in two passes.  Since x.c and X.C
> describe the same file, it is not possible to rename it directly:
>
>   cpu% touch X.C
>   cpu% mv X.C x.c
>   mv: X.C and ./x.c are the same
>
> Just try something like this:
>
>   cpu% mv X.C _x.c
>   cpu% mv _x.c x.c
>   cpu% ls *.c
>   x.c
>   cpu%

That's exactly what I did, however, from what I could see, it only
worked if mv'd on Plan 9.

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] FAT32 question

[tlaronde]

On Wed, Mar 27, 2013 at 08:24:57AM -0400, Comeau At9Fans wrote:
>
> I do believe that historically there was some sort of interpretations
> such as this in the evolution from FAT to FAT32, but not sure it
> should be so in current version, or, at least, other operating systems
> don't take this interpretation.  Is there an option or something I'm
> missing?  How do I get to process x.c as x.c and not X.C.
>

For "other operating systems", in one office where I happen to do work
from time to time, there is a fileserver and various versions of
Windows and an Unix I have put.

I have been unable to understand how the capitalized letters
are taken or dropped in filenames. You can create a file on a Windows,
and the name appearing when mounting the fileserver with NFS is
different from what you typed, and may be different from what a Windows
chows.

Just to mention that this may not be a 9 idiosynchracy but
something to do with curious "rules" in the FAT32 and 8.3 transition.
(Even if in my example, there is no FAT32 left, there are NTFS on NTs
and whatever by default on Windows XP or Windows 7.)
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] FAT32 question

[dexen deVries]

On Wednesday 27 of March 2013 08:24:57 Comeau At9Fans wrote:
> I'm mounting a FAT32 flashdrive on a RPi.  However, it seems that some
> sort of legacy 8.3 filename situation is existing.  For instance, if I
> have a directory containing x.c and a23456789.c that the former is
> taken as X.C and the latter is taken as shown.  Therefore, to compile
> x.c is not possible.  So for instance, echo *.c produces a different
> result than echo *.C.  I tried mv'ing the problem files and then back
> but same results.
> 
> I do believe that historically there was some sort of interpretations
> such as this in the evolution from FAT to FAT32, but not sure it
> should be so in current version, or, at least, other operating systems
> don't take this interpretation.  Is there an option or something I'm
> missing?  How do I get to process x.c as x.c and not X.C.


there's no difference between FAT12/16 and FAT32 in treatment of file names, it 
is entirely up to FS driver to create or skip creation of LFN (Long File Name) 
entry, and to use or skip reading an LFN.

every file on FAT has 8.3 name, and may, but does not have to have, an LFN. the 
8.3 name is of limited charset (one of DOS or WINDOWS codepages) and upcase 
only, at least in canonical format. to store lowercase characters, you need 
LFN.

IIRC, some version(s?) of fat drivers on linux did not create LFN for a file 
when the long filename was matching case INsensitive the 8.3 file name, 
essentially leading to loss of character case information.

perhaps something alike is at play here.

-- 
dexen deVries

[[[↓][→]]]


``we, the humanity'' is the greatest experiment we, the humanity, ever 
undertook. 

Re: [9fans] FAT32 question

[Stuart Morrow]

substfs, trfs

Re: [9fans] FAT32 question

[Bakul Shah]

On Mar 27, 2013, at 5:24 AM, Comeau At9Fans <comeauat9fans@gmail.com> wrote:

> I'm mounting a FAT32 flashdrive on a RPi.  However, it seems that some
> sort of legacy 8.3 filename situation is existing.  For instance, if I
> have a directory containing x.c and a23456789.c that the former is
> taken as X.C and the latter is taken as shown.  Therefore, to compile
> x.c is not possible.  So for instance, echo *.c produces a different
> result than echo *.C.  I tried mv'ing the problem files and then back
> but same results.
> 
> I do believe that historically there was some sort of interpretations
> such as this in the evolution from FAT to FAT32, but not sure it
> should be so in current version, or, at least, other operating systems
> don't take this interpretation.  Is there an option or something I'm
> missing?  How do I get to process x.c as x.c and not X.C.

mv failed to cure it of its uppercase probably because the X.C slot in the patent dir. was reused when you renamed it back. Copy everything to a brand new directory using lowercase names and see if that works. The broader lesson is to *not* use FAT fs with tools that expect case sensitive file systems.