[MLton] cygwoes

Matthew Fluet fluet@cs.cornell.edu
Wed, 5 Oct 2005 10:07:12 -0400 (EDT)


>> Somehow, my path has been changed to lowercase (it should be 
>> mlton.svn.HEAD, not mlton.svn.head).  I renamed my path to the lowercase 
>> version, hoping to avoid that issue.
>
> Uhm. Aren't windows filenames case insensitive?
> It is getting converted to lower-case because our implementation of 
> OS.Path lower-cases everything in compliance with the standard....
>
> "
> In a Microsoft Windows implementation, canonical paths are entirely 
> lowercase.
> "
>
> Or is it the case that *cygwin* somehow makes things case dependent?

Cygwin has an environment variable option that affects case-sensitivity. 
When it is active, it does not allow you to "pun" and access a file along 
a path that differs in case; though, it still prevents you from creating a 
file with the same name, but different case.

I note that this Cygwin option has been deprecated since I added it to my 
Cygwin startup; perhaps it's behavior has changed behind the scenes.

> Also, your path "/home\fluet\mlton\mlton.svn.head\build\lib/target-map" 
> looks broken to me. The first "/" is ok; it is a cygwin specific hack to 
> get access to the virtual (fake) filesystem root. However, the last '/' 
> should be a '\'. Why isn't it?

The last separator is '/' and not '\' because  mlton/main/main.fun:72 
constructs the path via
   concat [!Control.libDir, "/target-map"]
and the path is never canonicalized before being opened.

> From what (little) I understand of cygwin, I think this is due to the 
> fork/exec code. However, do we know which code-path is being used? 
> fork/exec or spawnp?

It should be spawnp, since fork/exec is disabled when we use 
Virtual{Alloc,Free} instead of {mmap,free}.

> What was the original reason for avoiding mmap? Does it still apply?

We originally avoided mmap and fork because of Cygwin bugs.
    http://mlton.org/RunningOnCygwin
Newer versions of Cygwin seem to have fixed that buggy interaction (hence, 
the  @MLton use-mmap --  runtime option seems to work now), but possibly 
at the expense of bugging the Virtual{Alloc,Free} code.