Hi John,

I still haven't got a Mac machine for testing purposes, but with Comanche 6.1 there is still a lingering issue on the Mac VM. I put a work around in for the #exists issue and that fixed file serving in Comanche 6.1, but I've gotten reports that auto generated directory indexes cause the server to go into some sort of infinite loop. The problem can be observed if you install Comanche 6.1 (it's KomHttpServer on SqueakMap), start a basic file server (see the class comments in KomHttpServerInfo and evaluate the first example), and then point your browser to http://localhost:8080/ ...this should get you an auto generated listing of the files in your Squeak default directory (provided that you don't have an index.htm or index.html file in that directory), but on the Mac I think it goes into an infinite loop (at least with the older VM). It works on Windows and Linux.

If you wanted to debug it, you might want to drop the priority level of the httpd service using:

(Service serviceNamed: 'httpd') stop; priority: Processor userBackgroundPriority; start

The problem seems like it is most likely happening in: ModAutoIndex>>directoryListing:directory:

Anyway, I'm curious if this problem is still occurring in your latest VM, and if there might be a work around or VM fix that might get this working consistently across all platforms. If you don't have the time, don't worry about it...I'm hoping that I can get an old Mac for testing purposes in the next couple of weeks.

BTW, do you happen to have an old OS9 system CD that you'd be willing to part with? I've located a Mac that I can get on loan (from Joshua), but he's lost his system CDs.

- Stephen

John M McIntosh wrote:

This is fixed in the macintosh squeak vm 3.5.1 which will ship real soon now. The issue was asking for a directory index of 1 on a file, resolved back to a no-more files, versus an error (bad path name) when you attempted to ask for a directory index entry on a file.

On Monday, May 19, 2003, at 11:54 AM, Lukas Renggli wrote:

...

Hi all,

I just discovered that the message FileDirectory>>exists is returning true, even when the receiver is a file and not a directory. I am currently working with a 3.5-5180 image on Mac OS X. The tests FileDirectoryTests>>testDirectoryExists, >>testExists and

...

...

testDeleteDirectory do also fail in that configuration. It seem to

work with Windows, so I think this is a platform related problem.

Cheers Lukas

--

=== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

I think I'm seeing this problem on Linux as well. I just downloaded a fresh Squeak 3.5 from squeak.org, then installed KomHttpServer 6.1 from SqueakMap. I let it install everything it suggested. Now, when I start a basic file server, and point the browser to localhost:8080, Squeak hangs and I have to kill it and relaunch it to regain control. I'm running RedHat 8.0.

Any of the Kom modules that don't try to do file serving seem to work, though.

Nevin

Stephen Pair wrote:

Hi John,

I still haven't got a Mac machine for testing purposes, but with Comanche 6.1 there is still a lingering issue on the Mac VM. I put a work around in for the #exists issue and that fixed file serving in Comanche 6.1, but I've gotten reports that auto generated directory indexes cause the server to go into some sort of infinite loop. The problem can be observed if you install Comanche 6.1 (it's KomHttpServer on SqueakMap), start a basic file server (see the class comments in KomHttpServerInfo and evaluate the first example), and then point your browser to http://localhost:8080/ ...this should get you an auto generated listing of the files in your Squeak default directory (provided that you don't have an index.htm or index.html file in that directory), but on the Mac I think it goes into an infinite loop (at least with the older VM). It works on Windows and Linux.

If you wanted to debug it, you might want to drop the priority level of the httpd service using:

(Service serviceNamed: 'httpd') stop; priority: Processor userBackgroundPriority; start

The problem seems like it is most likely happening in: ModAutoIndex>>directoryListing:directory:

...

Uggg...well, it appears that some code that I put in to work around the problem on the Mac has broken the Linux implementation. The problem on Linux is that the test FileStream class>>isAFileNamed: will return true even if the argument is a directory (not a file).

If you change the test in ModDir class>>directoryExists: to simply answer "aFileDirectory exists" then it should correct things for Linux. It seems I may have to resort to testing which platform we're running on in order to get this thing working consistently on all platforms. What a pain. I'll look more into it this evening.

- Stephen

Nevin Pratt wrote:

A minor correction.

When I do this, the first time I point the browser (NetScape 7.1 on RH 8.0) to localhost:8080, I get a dialog:

---

You have chosen to download a file of type: "Binary Executable" [application/octet-stream] from http://localhost:8080/

What should Netscape do with this file?

O Open using an application X Save this file to disk

---

Anyway, if I cancel, then Squeak hangs. If I say to Save this file to disk, it gives me a weird filename to save. The filename changes each time I try it-- just now it wanted to save "aut9pk86.exe". If I then click "Save", Netscape waits forever for data to come down the line to save. And whether I click "Save" or "Cancel", Squeak is hung-- I have to kill it and relaunch.

Anyway, I do think it is related to the same problem you reported.

Nevin

Nevin Pratt wrote:

...

I think I'm seeing this problem on Linux as well. I just downloaded a fresh Squeak 3.5 from squeak.org, then installed KomHttpServer 6.1 from SqueakMap. I let it install everything it suggested. Now, when I start a basic file server, and point the browser to localhost:8080, Squeak hangs and I have to kill it and relaunch it to regain control. I'm running RedHat 8.0.

Any of the Kom modules that don't try to do file serving seem to work, though.

Nevin

Stephen Pair wrote:

...

Hi John,

I still haven't got a Mac machine for testing purposes, but with Comanche 6.1 there is still a lingering issue on the Mac VM. I put a work around in for the #exists issue and that fixed file serving in Comanche 6.1, but I've gotten reports that auto generated directory indexes cause the server to go into some sort of infinite loop. The problem can be observed if you install Comanche 6.1 (it's KomHttpServer on SqueakMap), start a basic file server (see the class comments in KomHttpServerInfo and evaluate the first example), and then point your browser to http://localhost:8080/ ...this should get you an auto generated listing of the files in your Squeak default directory (provided that you don't have an index.htm or index.html file in that directory), but on the Mac I think it goes into an infinite loop (at least with the older VM). It works on Windows and Linux.

If you wanted to debug it, you might want to drop the priority level of the httpd service using:

(Service serviceNamed: 'httpd') stop; priority: Processor userBackgroundPriority; start

The problem seems like it is most likely happening in: ModAutoIndex>>directoryListing:directory:

...

...

Ok Well I fixed the issue of exists: in the MAC VM 3.5.1b2.

However now that exists: if it's a directory is ok, and considering the bug below according Stephen's note the fallback position causes the logic to open the file using unix fopen, then do a read using unix fread. That exposes another BUG.

You see we ask for N bytes and the primitive

size_t sqFileReadIntoAt(SQFile *f, size_t count, int byteArrayIndex, size_t startIndex) {} actually returns 0 bytes were read with ferror(stream) set to true { I checked that manually, we don't check in the production primitive}.

However this does not cause a primitive failure, now according to the man page, returning less bytes or zero than asked for in the fread requires one to examine ferror(stream) or feof(stream) to see if the less bytes or zero is an issue with an error, or the fact you hit end of file. So we don't check ferror(stream), and the code in

httpResponse>>pvtWriteContentsOn: aStream

checks only atEnd which is always fails because the size of the file is

0 and the position is zero, so it loops forever! reading 0 bytes from

the file stream not realizing downbelow lurks an error.

Somehow I think we need to resolve this.

a) Perhaps invoke a primitive failure if ferror() is true after the read? (write has similar check too?) b) Cleanup places where you do a read so that if zero comes back that's a error. This only requires smalltalk code but solution (a) is better because people won't remember to make the correct check in other code of this type where one assumes reading on a stream that isn't AtEnd should always return bytes to increment a counter/etc versus doing nothing forever. c) Ah have an Sunit test that nails down file io on files, directories, volumes (mac). So that we really understand that what isAFile versus isADirectory versus attempting to do a directory means for Squeak. This does apply to any rewrite, I'd hope that OS errors on read/write (such as read/write permissions or unknown actually peculate upwards?)

PS oh and in doing this I tripped over an issue with unix sockets I'll detail later once I understand why.

ZEROZWEROZERO On Monday, June 9, 2003, at 06:18 AM, Stephen Pair wrote:

Uggg...well, it appears that some code that I put in to work around the problem on the Mac has broken the Linux implementation. The problem on Linux is that the test FileStream class>>isAFileNamed: will return true even if the argument is a directory (not a file).

If you change the test in ModDir class>>directoryExists: to simply answer "aFileDirectory exists" then it should correct things for Linux. It seems I may have to resort to testing which platform we're running on in order to get this thing working consistently on all platforms. What a pain. I'll look more into it this evening.

• Stephen

Nevin Pratt wrote:

...

A minor correction.

When I do this, the first time I point the browser (NetScape 7.1 on RH 8.0) to localhost:8080, I get a dialog:

---

You have chosen to download a file of type: "Binary Executable" [application/octet-stream] from http://localhost:8080/

What should Netscape do with this file?

O Open using an application X Save this file to disk

---

Anyway, if I cancel, then Squeak hangs. If I say to Save this file to disk, it gives me a weird filename to save. The filename changes each time I try it-- just now it wanted to save "aut9pk86.exe". If I then click "Save", Netscape waits forever for data to come down the line to save. And whether I click "Save" or "Cancel", Squeak is hung-- I have to kill it and relaunch.

Anyway, I do think it is related to the same problem you reported.

Nevin

Nevin Pratt wrote:

...

I think I'm seeing this problem on Linux as well. I just downloaded a fresh Squeak 3.5 from squeak.org, then installed KomHttpServer 6.1 from SqueakMap. I let it install everything it suggested. Now, when I start a basic file server, and point the browser to localhost:8080, Squeak hangs and I have to kill it and relaunch it to regain control. I'm running RedHat 8.0.

Any of the Kom modules that don't try to do file serving seem to work, though.

Nevin

Stephen Pair wrote:

...

Hi John,

I still haven't got a Mac machine for testing purposes, but with Comanche 6.1 there is still a lingering issue on the Mac VM. I put a work around in for the #exists issue and that fixed file serving in Comanche 6.1, but I've gotten reports that auto generated directory indexes cause the server to go into some sort of infinite loop. The problem can be observed if you install Comanche 6.1 (it's KomHttpServer on SqueakMap), start a basic file server (see the class comments in KomHttpServerInfo and evaluate the first example), and then point your browser to http://localhost:8080/ ...this should get you an auto generated listing of the files in your Squeak default directory (provided that you don't have an index.htm or index.html file in that directory), but on the Mac I think it goes into an infinite loop (at least with the older VM). It works on Windows and Linux.

If you wanted to debug it, you might want to drop the priority level of the httpd service using:

(Service serviceNamed: 'httpd') stop; priority: Processor userBackgroundPriority; start

The problem seems like it is most likely happening in: ModAutoIndex>>directoryListing:directory:

...

...

--

• Stephen

---

Do you need: Web/Domain/Application Hosting? Mailing List Services? IMAP/POP3/Web Email Accounts? Instant Messaging Accounts hosted on your domain?

Email me for information.

-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

On Tuesday, June 10, 2003, at 06:52 AM, Ned Konz wrote:

...

However now that exists: if it's a directory is ok, and considering the bug below according Stephen's note the fallback position causes the logic to open the file using unix fopen, then do a read using unix fread. That exposes another BUG.

Isn't it possible for a file to exist but not actually be readable?

Sure, via permissions you can deny yourself read access to your own file.

I'd much prefer to expose stat() to the Squeak layers for Unix boxes.

Like the work you've done on the serial ports, it makes sense for some of this stuff to actually take care of the platform differences at the Squeak level, rather than in the primitives.

Mmm thought/hope someone was rewriting, reviewing the file/steam classes, like the socket stuff. Is stat() exist across *all* unix or unix like or clib supported systems?

-- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE

-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

On Tue, Jun 10, 2003 at 12:33:36PM -0700, John M McIntosh wrote:

Mmm thought/hope someone was rewriting, reviewing the file/steam classes, like the socket stuff. Is stat() exist across *all* unix or unix like or clib supported systems?

The stat() and fstat() calls go way back, and would be available on any unix system. Both calls are documented in "The UNIX System", by S. R. Bourne, 1983 (an older book that happens to be readily at hand).

According to a recent Debian Linux man page: The stat and fstat calls conform to SVr4, SVID, POSIX, X/OPEN, BSD 4.3. The lstat call conforms to 4.3BSD and SVr4.

Dave