[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?

[erik quanstrom]

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

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

[Comeau At9Fans]

Post by erik quanstrom

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

[Nicolas Bercher]

Post by Comeau At9Fans

Post by erik quanstrom

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

[Comeau At9Fans]

Post by Nicolas Bercher

... 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
cpu% touch X.C
cpu% mv X.C x.c
mv: X.C and ./x.c are the same
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?

[t***@polynum.com]

Post by Comeau At9Fans
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.)

[dexen deVries]

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

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.

[Stuart Morrow]

substfs, trfs

[Bakul Shah]

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

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.