irritating Go 1.1 issue: case-insensitive file name collision:

[Erwin]

I upgraded to Go 1.1.1 (late, i know...) and found out that some of my packages no longer compile without errors. An example of this new type of error:

../OrbitCamera.go:10:2: case-insensitive file name collision: "Vec3F.go" and "Vec3f.go"

Vec3F.go and Vec3f.go are parts of my vector package. Why two names so similar? Well, Vec3F is a float64 based 3D vector, Vec3f is a float32 based one. I put the source for these types in separate files, and it used to work fine with Go 1.0.3.

Is there a way around this other than renaming my files / putting the variant implementations in a single file? Why is this case-insensitive restriction there at all?

Thanks for any insights

[Dave Cheney]

Some supported platforms have case insensitive case preserving file systems. 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Erwin]

Some supported platforms have case insensitive case preserving file systems. 

Like?

 

[Wes Freeman]

On Wed, Jul 3, 2013 at 8:27 PM, Erwin <snes...@gmail.com> wrote:

Some supported platforms have case insensitive case preserving file systems. 

Like?

Windows, I imagine.

[Dave Cheney]

Bzzzt, OS X. 

[Wes Freeman]

Wow, I didn't realize OS X was case insensitive. And it's my primary OS at the moment. That's pathetic (that I didn't know, and also that it's actually case insensitive--all things should be case sensitive IMO). And windows is, too, for the record. :)

Wes

[Dave Cheney]

You should direct your ire to Apple for continuing to saddle us with the yoke of HFS+. 

[Steven Hartland]

I'd guess Windows, but you can enable case-sensitive if you want its just
not default because MS throught users are stupid ;-)

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postm...@multiplay.co.uk.

[Erwin]

Bzzzt, OS X. 

Odd, my file naming scheme using F/f I/i to indicate float64/float32 int64/int32 used to work fine on OS X with Go < 1.1

I have seen it happen on USB sticks though, that are formatted FAT32 or something, so I can imagine the need for such a check. I figure this is a 'growing pain' of Go, and that i just have to find another neat solution for my filename variants...

 

[Eli Janssen]

You can format your HFS+ file system as case sensitive.
It is a format-time option.

Maybe at some point in the past you reformatted as case sensitive?

[brainman]

Go is warning you that on some systems "Vec3F.go" and "Vec3f.go" might be referring to the same file. Renaming is the only way I know.

Alex

[Erwin]

You can format your HFS+ file system as case sensitive.
It is a format-time option.

Maybe at some point in the past you reformatted as case sensitive?

No I didn't. It always simply worked on stock Macs.   

[Erwin]

On 4 July 2013 10:49, Jim Robinson <jim.ro...@gmail.com> wrote:

Try typing this on your OS X shell, does it work or return an error?

$ ls /USERS/

Ha, that doesn't return an error. Maybe the shell is doing something with the case? Anyway, I have solved my issue with the conflicting names of package files, and move on with coding :)

 

[Erwin]

After having a closer look, indeed: OS X won't accept two files like A.txt and a.txt in the same directory. It must have been a while since I tested my recent packages on OS X, or I would have noticed it earlier. Now I fully understand why Go1.1 has this security check.

[Joseph Poirier]

Of course it will:

On Thu, Jul 4, 2013 at 5:10 AM, Erwin <snes...@gmail.com> wrote:

After having a closer look, indeed: OS X won't accept two files like A.txt and a.txt in the same directory. It must have been a while since I tested my recent packages on OS X, or I would have noticed it earlier. Now I fully understand why Go1.1 has this security check.

[Christopher Nielsen]

It will *ONLY* if you have your drive formatted as case-sensitive. I think the OP has the drive formatted as case-insensitive, the default.

--
Christopher Nielsen
"They who can give up essential liberty for temporary safety, deserve neither liberty nor safety." --Benjamin Franklin
"The tree of liberty must be refreshed from time to time with the blood of patriots & tyrants." --Thomas Jefferson

[Joseph Poirier]

On Thu, Jul 4, 2013 at 8:37 AM, Christopher Nielsen <m4dh...@gmail.com> wrote:

It will *ONLY* if you have your drive formatted as case-sensitive. I think the OP has the drive formatted as case-insensitive, the default.

Correct; my second screen pic shows Case-sensitive journaled, but his last post made a general statement about OSX not allowing files with the same names but with case difference in the same folder, which is misleading. 

[Christopher Nielsen]

Gotcha. Missed that part. Mea culpa. :-)

[Joseph Poirier]

No problem. 

I'm not sure why Go overrides the OS's settings and does the  "Check for case-insensitive collision of input files " in pkg.go? 

Python doesn't have this behavior, my diff/merge tools don't either, nor do any of my c/c++ compilers. And IMHO it's not something that the Go build tool should be concerned with. Stating that it's for security reasons is specious, and naive. If an OS has its standard file system API attribute set as case-insensitive it won't allow files with the same name in the same directory that differ only in case to be created, any further checking is outside of the Go tools domain.     

[Mateusz Czapliński]

On Thursday, July 4, 2013 5:07:02 PM UTC+2, Joe Poirier wrote:

I'm not sure why Go overrides the OS's settings and does the  "Check for case-insensitive collision of input files " in pkg.go? 

Python doesn't have this behavior, my diff/merge tools don't either, nor do any of my c/c++ compilers. And IMHO it's not something that the Go build tool should be concerned with. Stating that it's for security reasons is specious, and naive. If an OS has its standard file system API attribute set as case-insensitive it won't allow files with the same name in the same directory that differ only in case to be created, any further checking is outside of the Go tools domain.     

If I were to speculate, I'd suppose it is to ensure that when a package is "go-gettable" on one Supported Platform, then it is also easily "go-gettable" on any other Supported Platform, without sudden errors.

/M.

[Nick Craig-Wood]

I'd agree. And having made exacly that mistake in a large C++ codebase
in the past which caused quite a bit of trouble when porting it to
Windows, I'd say it was a very good idea.

On my linux machine

$ cd /tmp/
$ mkdir a
$ cd a
$ echo 'package main' > a.go
$ echo 'package main' > A.go
$ ls
a.go A.go
$ go build
can't load package: package .: case-insensitive file name collision:
"A.go" and "a.go"
$

+1 for go :-)

--
Nick Craig-Wood <ni...@craig-wood.com> -- http://www.craig-wood.com/nick

[minux]

On Thu, Jul 4, 2013 at 11:07 PM, Joseph Poirier <jdpo...@gmail.com> wrote:

I'm not sure why Go overrides the OS's settings and does the  "Check for case-insensitive collision of input files " in pkg.go? 

To fix https://code.google.com/p/go/issues/detail?id=4773

[Joseph Poirier]

So it's to cover up spelling errors :) 

[Mateusz Czapliński]

"The goal is to do something [...] so that people do not inadvertently create packages that cannot be built on Windows."
https://code.google.com/p/go/issues/detail?id=4773#c5

/M.

[bugpowder]

On Thursday, July 4, 2013 3:38:45 AM UTC+3, Steven Hartland wrote:

I'd guess Windows, but you can enable case-sensitive if you want its just
not default because MS throught users are stupid ;-)

Or, you know, smart.

The main benefit of a case sensitive FS is making the life of developers and the machine easier. 

It's how a programmer, conditioned by the machine thinks.

In actual life, photo.jpg and Photo.jpg are not supposed to be conceptually different.

[Henrik Johansson]

Yet we often use CASE to convey subtle human meanings....

[bugpowder]

On Friday, July 5, 2013 9:43:45 PM UTC+3, Henrik Johansson wrote:

Yet we often use CASE to convey subtle human meanings....

And we rightly frown upon that kind of use, and consider it rude ("shouting").

Plus it's not used for a semantic distinction, but one of tone. The two words still convey the same meaning in shouting and no shouting mode.

[Henrik Johansson]

My intention was actually not to be rude but to point out that we do use case for things not solely of value to programmers and machines.

[bugpowder]

On Friday, July 5, 2013 9:56:42 PM UTC+3, Henrik Johansson wrote:

My intention was actually not to be rude but to point out that we do use case for things not solely of value to programmers and machines.

Oops, I'm sorry, didn't want to imply you were rude! 

Just that the kind of "use of uppercase" you pointed to (and not actually used yourself of course) is considered rude.

But I think the core of the matter re: case sensitivity (and I have digressed way past Go now), is that people don't really make semantic distinctions on the contents of files based on their case. 

Programmers do -- and part of the reason is because they know there's a different at the encoding level, the byte sequence stored to represent the name etc. 

A user thinks in a much higher conceptual plane.

[Joseph Poirier]

How does the CL fix it so packages that couldn't previously be built on Windows-when the correct spelling was used-can be built now? The original problem was fixed when the correct spelling of the imported package was used, i.e. from math/Rand to math/rand, which is the way it should work, and still does. The CL goes on to use a heavy handed approach for doing case-insensitive file handling even if the system is case-sensitive; the input file collision should only be a collision when on a case-insensitive system.

[Wes Freeman]

I think it makes sense to handle it this way, heavy handed as it might be. It's certainly easy enough to change names of files to something possibly even more descriptive--like the OP with F and f might consider f32 and f64 instead. At which point his package can be usable on mac and windows. I don't see this ever causing a serious problem for people who might be slightly inconvenienced by the approach, since it's an easy workaround. 

[minux]

On Saturday, July 6, 2013, Joseph Poirier wrote:

On Fri, Jul 5, 2013 at 3:41 AM, Mateusz Czapliński <czap...@gmail.com> wrote:

On Thursday, July 4, 2013 6:50:24 PM UTC+2, Joe Poirier wrote:

On Thu, Jul 4, 2013 at 10:38 AM, minux <minu...@gmail.com> wrote:

On Thu, Jul 4, 2013 at 11:07 PM, Joseph Poirier <jdpo...@gmail.com> wrote:

I'm not sure why Go overrides the OS's settings and does the  "Check for case-insensitive collision of input files " in pkg.go? 

To fix https://code.google.com/p/go/issues/detail?id=4773

So it's to cover up spelling errors :) 

"The goal is to do something [...] so that people do not inadvertently create packages that cannot be built on Windows."
https://code.google.com/p/go/issues/detail?id=4773#c5

How does the CL fix it so packages that couldn't previously be built on Windows-when the correct spelling was used-can be built now? 

could you please post an example program that demonstrate that CL is

incorrect in this regard? 

[cxza...@gmail.com]

Agreed on all points. In addition, I would like to point out that Go itself is case-sensitive. More importantly, Go makes an important distinction between identifiers that start with a capital letter versus a lowercase letter, and a good convention is to name files after the struct/interface they define.

Also, while A and a are conceptually equivalent for the most part, they are not in fact the same character! Being different, they should be treated as different. Simple as that.

At the same time, I realize that the check was added to prevent code that works on ext4 can be acquired correctly into NTFS or FAT. However, I suggest that it should not be the "build" action that checks this. Rather, the "get" action should check it as it downloads the files. If it would overwrite a file already downloaded, display an error and stop. There is no sense limiting everyone to the weakest link - pretty soon, symbolic links won't be allowed, or file permissions, or...the list goes on, especially for those who never intend their code to be used externally (as is my case).

[Jakob Borg]

2013/11/13 <cxza...@gmail.com>:
> Agreed on all points. I would also like to point out that Go itself is
> case-sensitive. Also, even if A and a (and À, ä, and ą, for that matter)
> have the same "meaning", as is suggested (they don't), they are, in fact,
> different characters. Thus, they should be treated as different characters.
> Simple as that.
>
> At the same time, I can understand (grudgingly) that if the go tool is
> intended to be cross-platform (or at least available for disparate
> platforms), it would need to target the least common feature-set. However,
> this check seems very heavy-handed and out of place. I suggest that the
> functionality be moved to the "go get" action and only show an error if
> there would be a filename conflict on the target filesystem. Something like
> "go get a real filesystem, ya bum!" seems appropriate :)

I sometimes feel the Go toolchain is accumulating a bit too much
special case magic. This could be one example.

Another that comes to mind is "go get" installing binaries in
different places for certain import paths. I get that it's supposed to
avoid confusion when someone installs godoc and gets the binary in the
same place it was before the breakout, but it was very surprising
indeed to me when "go get code.google.com/..../godoc" as a regular
user failed with a permission denied error for a directory way outside
my $GOPATH. It took digging into the source to find out why godoc
didn't end up in ~/bin as I expected it to.

Special handling of import paths that look like URLs of common source
hosting services could be another. It's supremely convenient to be
sure, but it could be argued that it spawned the entire "Go doesn't
manage my versions for me, how will I ever be able to do a
reproducible build?" misunderstanding.

</moaning> That said, it's still language + toolchain of choice and
living with gccgo and no go tool isn't that much fun at all. :)

//jb