Case sensitivity issue in repo

[GoogleCodeExporter]

What happened:
When plan9front is cloned with `hg clone https://code.google.com/p/plan9front/` 
on OS X, the clone fails with:

updating to branch default
abort: case-folding collision between rc/bin/kill and rc/bin/Kill

HFS+ is case-insensitive and case-preserving by default.

What was expected:
No files with identical names except for case in the repository.

Steps to reproduce:
0. Use OS X 10.9.5 or equivalent
1. Clone repo with `hg clone https://code.google.com/p/plan9front/`
2. Cloning fails

Original issue reported on code.google.com by alexchan...@gmail.com on 28 Sep 2014 at 8:33

[GoogleCodeExporter]

There's also:
`abort: case-folding collision between sys/lib/postscript/troff/Hx and 
sys/lib/postscript/troff/HX`

Original comment by alexchan...@gmail.com on 28 Sep 2014 at 8:52

[GoogleCodeExporter]

Get a real computer.

Original comment by a...@phicode.de on 28 Sep 2014 at 8:53

• Changed state: ThereIsNoBug

[GoogleCodeExporter]

You're killing me, guys:

`abort: case-folding collision between sys/lib/troff/font/devutf/Hb and 
sys/lib/troff/font/devutf/HB`
`abort: case-folding collision between sys/lib/troff/font/devutf/Hi and 
sys/lib/troff/font/devutf/HI`
`abort: case-folding collision between sys/lib/troff/font/devutf/Hx and 
sys/lib/troff/font/devutf/HX`
`abort: case-folding collision between sys/lib/troff/font/devutf/charlib/lH and 
sys/lib/troff/font/devutf/charlib/LH`
`abort: case-folding collision between sys/lib/troff/font/devutf/charlib/rc and 
sys/lib/troff/font/devutf/charlib/RC`
`abort: case-folding collision between sys/lib/troff/font/devutf/charlib/rh and 
sys/lib/troff/font/devutf/charlib/rH`
`abort: case-folding collision between sys/src/cmd/postscript/devpost.add/c1 
and sys/src/cmd/postscript/devpost.add/C1`
`abort: case-folding collision between sys/src/cmd/postscript/devpost.add/c2 
and sys/src/cmd/postscript/devpost.add/C2`
`abort: case-folding collision between sys/src/cmd/postscript/devpost.add/c3 
and sys/src/cmd/postscript/devpost.add/C3`

Could someone remove the conflicting files?

Original comment by alexchan...@gmail.com on 28 Sep 2014 at 9:06

[GoogleCodeExporter]

> Get a real computer.

Come on. It costs you *nothing*. It's not a compromise of principles like 
adding Berkeley Sockets or something. It's allowing someone to compile your 
code.

And it costs you *NOTHING*.

Original comment by alexchan...@gmail.com on 28 Sep 2014 at 9:10

[GoogleCodeExporter]

Just set your OS to case sensitive, as it should be. Next, people will demand 
8.3 compatible file names so that they compile on DOS.

How are you even planning on compiling 9front on OS X? gcc can "mostly" compile 
Plan 9 code (i.e. "only" a couple errors per KLOC), llvm can not at all (i.e. 
there is no hope).

Original comment by a...@phicode.de on 28 Sep 2014 at 9:16

[GoogleCodeExporter]

> Come on. It costs you *nothing*.

this is wrong, it would cost us a lot. the plan 9 file systems are case 
sensitive. you are using a crippled file system on another os. the problem is 
not with plan 9, the problem is that you are using a case-insensitive file 
system. as aiju pointed out, all you have to do is turn on case-sensitivity in 
your file system. it costs you nothing and it requires no changes to plan 9.

Original comment by stanley....@gmail.com on 28 Sep 2014 at 9:26

[GoogleCodeExporter]

> Just set your OS to case sensitive, as it should be. Next, people will demand 
8.3 compatible file names so that they compile on DOS.

That's the slippery slope fallacy, and it's wrong. There's a huge difference 
between renaming 10 files, and forcing DOS compatibility on the entire 
repository. DOS is a 30 year old system, and demanding that Plan 9 be--not only 
cloneable--but *COMPILABLE* on DOS is a completely unreasonable request.

As it stands, I can't even view the source on OS X except through the Google 
Code source browser, because 10 files have similar names. It's not unreasonable 
to avoid case collisions, or allow the repository to be checked out on a case 
sensitive filesystem like the current versions of OS X and winblows use. I 
can't even begin to *attempt* to compile Plan 9 using some clever method unless 
you let me check out the source.

Original comment by alexchan...@gmail.com on 28 Sep 2014 at 9:33

[GoogleCodeExporter]

> all you have to do is turn on case-sensitivity in your file system
This can't be done for HFS+ without repartitioning, i.e. wiping my HD. And a 
fair amount of OS X software breaks with case sensitivity. I'm not defending 
this, it's just a fact. I have one laptop, and I simply want to clone Plan 9.

> this is wrong, it would cost us a lot. the plan 9 file systems are case 
sensitive. you are using a crippled file system on another os.
No it wouldn't. It would cost nothing more than renaming 10 files (or removing 
any that are extraneous). This isn't about dropping case-sensitivity at all. 
This is merely allowing the repo to be *viewed* on case sensitive systems.

Original comment by alexchan...@gmail.com on 28 Sep 2014 at 9:44

[GoogleCodeExporter]

And 9/10 of these conflicts are between identical files:

`abort: case-folding collision between sys/lib/postscript/troff/Hx and 
sys/lib/postscript/troff/HX`
`abort: case-folding collision between sys/lib/troff/font/devutf/Hb and 
sys/lib/troff/font/devutf/HB`
`abort: case-folding collision between sys/lib/troff/font/devutf/Hi and 
sys/lib/troff/font/devutf/HI`
`abort: case-folding collision between sys/lib/troff/font/devutf/Hx and 
sys/lib/troff/font/devutf/HX`
`abort: case-folding collision between sys/lib/troff/font/devutf/charlib/lH and 
sys/lib/troff/font/devutf/charlib/LH`
`abort: case-folding collision between sys/lib/troff/font/devutf/charlib/rc and 
sys/lib/troff/font/devutf/charlib/RC`
`abort: case-folding collision between sys/lib/troff/font/devutf/charlib/rh and 
sys/lib/troff/font/devutf/charlib/rH`
`abort: case-folding collision between sys/src/cmd/postscript/devpost.add/c1 
and sys/src/cmd/postscript/devpost.add/C1`
`abort: case-folding collision between sys/src/cmd/postscript/devpost.add/c2 
and sys/src/cmd/postscript/devpost.add/C2`
`abort: case-folding collision between sys/src/cmd/postscript/devpost.add/c3 
and sys/src/cmd/postscript/devpost.add/C3`

Original comment by alexchan...@gmail.com on 28 Sep 2014 at 10:00

[GoogleCodeExporter]

alexchandel: this isn't an osx support group. nobody has any interest in making 
changes to plan 9 to support doing [who knows what] to its files on an 
unsupported operating system. it's not plan 9's fault you installed your osx 
file system without case sensitivity. just make better choices in the future. 
and get better tools.

Original comment by stanley....@gmail.com on 28 Sep 2014 at 11:00

[GoogleCodeExporter]

stanley: I'm not asking for an "osx support group" or any other red herring you 
came up with. The changes I proposed are quite unremarkable, and involve 
removing duplicated files. And they allow the source code to be cloned onto a 
case insensitive filesystem.

You could indulge an interested person with a trivial change allowing them to 
*view* source code, or you could rebuff them from the community with crass 
suggestions to "Get a real computer," or join "an osx support group," or "just 
make better choices in the future" and install "your osx file system without 
case sensitivity." Implying I ever installed this file system, or can format 
this computer's HD.

Original comment by alexchan...@gmail.com on 29 Sep 2014 at 1:08

[GoogleCodeExporter]

> abort: case-folding collision between rc/bin/kill and rc/bin/Kill

you're asking for more than just removing duplicate files. you're asking to 
restrict plan 9 file systems to case-insensitive behavior because you want to 
hg clone the 9front repo onto a case-insensitive file system. we don't support 
hg clone of the 9front repo onto case-insensitive file systems. it's really 
that simple. you've dug up an example of duplicate files that probably 
shouldn't exist, but you're now ignoring your own other examples such as Kill 
vs kill where the conflict is not caused by useless duplicates. how do you 
propose to address the Kill vs kill conflict?

thanks for filing all these bug reports, but nobody here is getting paid to 
indulge interested persons. or to validate your complaints, no matter how many 
times you repeat them.

Original comment by stanley....@gmail.com on 29 Sep 2014 at 1:18

[GoogleCodeExporter]

this is not just duplicated files. you need to change
tr2post and come up with a mangeling scheme. and stuff
doesnt stop here.
the problem is that mercurial cannot unpack
with these collisions. tho it goes to great
lengths mangeling the filenames of the repository
revlogs. maybe they'll fix this or provide an option
at some point. but nobody is going and make the 9front
tree macosx compliant. it is just too much trouble.
if you want access to the source, you could just
take it from the iso. it contains *everything*
unpacked already.

Original comment by cinap_le...@felloff.net on 29 Sep 2014 at 1:53

[GoogleCodeExporter]

> you're asking to restrict plan 9 file systems to case-insensitive behavior
No, I wasn't. Saying it multiple times doesn't make it true.

> this is not just duplicated files. you need to change tr2post and come up 
with a mangeling scheme.
cinap: Thank you for actually explaining the issue.

Inspired by the ISO suggestion, I created a case-sensitive disk image and 
cloned the repo into that. Problem solved. This is probably a good suggestion 
for future users with this problem.

Original comment by alexchan...@gmail.com on 2 Oct 2014 at 7:58

[GoogleCodeExporter]

Another solution if you only have one computer is to just install 9front in a 
VM. Then not only can you look at the code, but you can compile and run it 
easily.

Original comment by 23h...@gmail.com on 2 Oct 2014 at 8:17

[GoogleCodeExporter]

Plan 9 is about 10 years older than OS X. More than that, Plan 9 was designed 
with little to no concern for the norms and standards of Unix as it existed 
outside Bell Labs. It's just not like any unix or even any other OS; in places 
it takes approaches to problems which surprise most everyone. You're not going 
to get much out of it by just looking at the code. 

I'd second hiro's suggestion; install it in a VM where you can both try it and 
look at the code. Plan 9's plumber makes it simple to open files listed by ls 
or from the output of grep where the editor will jump to the line number given 
by grep. Plan 9's coding style makes it easy to find function definitions: grep 
-n '^funcname\(' *.c

If you really only want to look at the code without getting in so deep, I 
suggest looking at plan9port instead, it's developed on OS X.

Original comment by tereniao...@gmail.com on 2 Oct 2014 at 8:38

[GoogleCodeExporter]

For the record:

Those files are present *for good reason* and this is not a problem.  They will 
not ever be removed or renamed.  

Original comment by k...@sciops.net on 2 Oct 2014 at 9:05

• Added labels: Subsystem-Games