[racket] Question about sandbox.rktl failing its unit test

Folks,

I've just built racket-5.3.5 on Solaris-11 Intel (32 and 64 bit flavours).
Because I need to embed Racket into C, as well as run it standalone, I have
also built both the CGC (Boehm) and 3m (default) versions.

So that's four versions of racket. All of which seem to run with stability.

However, I have run the `all.rkt` test suite on all four, and it bails out
in sandbox.rkt with:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ /usr/local/racket-master/SunOS-5.11-amd64/bin/racketcgc -f 
/usr/local/racket-master/SunOS-5.11-amd64/lib/racket/collects/tests/racket/sandbox.rktl
[successful sandbox tests ending in...]
(#<procedure:run> #<procedure:...ket/sandbox.rktl:75:55>) ==> (exn: 
#(struct:exn:fail:contract "bytes-length: contract violation\n  expected: 
bytes?\n  given: #f" #<continuation-mark-set>))
   BUT EXPECTED (vals: 400000)
#t
[then about 10 further tests]
(#<procedure:run*> #<procedure:...ket/sandbox.rktl:73:55>) ==> 
(#<procedure:run*> #<procedure:...ket/sandbox.rktl:73:55>) ==> (exn: 
#(struct:exn:fail "current-load-relative-directory: `exists' access denied 
for 
/usr/local/racket-master/SunOS-5.11-amd64/lib/racket/collects/tests/racket/" #<continuation-mark-set>))
   BUT EXPECTED #t
(#<procedure:e-match?> "terminated .thread-killed.$" #<procedure:run> 
#<procedure:...ket/sandbox.rktl:76:55>) ==> #t
...
[snip]
...
[finishing in]
current-load-relative-directory: `exists' access denied for 
/usr/local/racket-master/SunOS-5.11-amd64/lib/racket/collects/tests/racket/
   context...:
 
/usr2/local/racket-master/SunOS-5.11-amd64/lib/racket/collects/racket/sandbox.rkt:611:0: 
evaluate-program
 
/usr2/local/racket-master/SunOS-5.11-amd64/lib/racket/collects/racket/private/more-scheme.rkt:146:2: 
call-with-break-parameterization
 
/usr2/local/racket-master/SunOS-5.11-amd64/lib/racket/collects/racket/sandbox.rkt:744:2: 
user-process
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It turns out that /usr/local is a symlink to /usr2/local (and therefore
/usr/local/racket... is physically located on /usr2/local/racket...).

The final exception is not one that is handled as an exception in the test
suite.

There are a number of questions raised:
   * is this failure, in sandbox checking `exists', an intended behaviour
     when the file in question is a symbolic link (or descendent)?
   * if not, is this a Solaris file system issue (does this problem not
     manifest itself on Linux)?
   * should the final exception be caught?
     And therefore increase the number of failed tests/exceptions?
     And allow the test suite to progress.

If someone could tell me how they would expect a symlink in a sandbox
to be handled, and if Solaris is not behaving as expected I'll take a look
at it.

Cheers,

Tim

-- 
Tim Brown <tim.brown at cityc.co.uk>  | City Computing Limited            |
T: +44 20 8770 2110                | City House, Sutton Park Road      |
F: +44 20 8770 2130                | Sutton, Surrey, SM1 2AE, GB       |
-----------------------------------------------------------------------|
BEAUTY:  What's in your eye when you have a bee in your hand           |
-----------------------------------------------------------------------'
City Computing Limited registered in London No. 1767817.
Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
VAT number 372 8290 34.