ar wrote:

>The GET request that I am testing is http://localhost:9000
>
>While processing this request my squeak image with Comanche hangs and I
>cannot interrupt it.
>

Try dropping the priority of the http service to userBackgroundPriority 
for better debugging.  This is now the default priority for services in 
Comanche 6.2.

>My server is set up to do some specialized processing or else pass the
>request to ModFile. When ModFile gets the above request, it forms a
>pathname using the documentroot and the url path which is ''. So for
>example, '/myroot/'.
>
>It then asks StandardFileStream isAFileNamed: '/myroot'/, which answers
>true. Later in the processing, in 
>
>HttpAdaptor>>writeResponse:for: it does
>
>[...] ensure: [response destroy]
>
>This is where the hangup occurs. I can't step into the #ensure: but
>#destroy is just doing a close to the stream on the directory.
>
>Anyone have a clue what might be going on? Should #isAFileNamed: be
>returning true for a directory? This is on Squeak 3.5 and Linux.
>

No, it should not...this has been a constant struggle for the file 
server capabilities that are built into Comanche 6.1 and 6.2.  There are 
(and have been) a number of subtle differences in the file system 
primitives among the different platform VMs.  I corrected some similar 
issues in ModDir relating to directory handling (see ModDir 
class>>directoryExists:)...looks like you may have stumbled on another 
similar issue but relating to file tests.  My guess is that it's trying 
to serve up the contents of a directory opened as a file (because 
isAFileNamed: is returning true for a directory)...the hang is likely 
being caused by trying to work with the directory as if it were a file.  
If you can find a solution to the issue for Linux, send it to me and 
I'll test it on Windows and Mac then update the Comanche 6.2 distribution.

- Stephen