Re: [9fans] FAT32 question

[Nicolas Bercher <nbercher@yahoo.fr>]

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