On Wednesday 13 November 2002 06:56 pm, Steve Gilbert wrote:
> I loaded a fresh 3.2 image from the Squeak3.2-4956-win-full.zip
> file. Then I pulled out a TestRunner and proceeded to Refresh and
> Run All. All tests passed.
>
> Then loaded code updates, moved system to 3.4alpha.
> Again in SUnit TestRunner, Refresh and Run All.
>
> But this time I get a quick flash of a filesystem hierarchy browser
> which disappears followed by this error.  A failed primitive
> deleting a directory that I check and is indeed there as is
> expected.
>

Goodie, detective work!

It looks like these tests were added in change set
 5017u28-fileDirTests-hg
which didn't exist in 3.2.

I think there is a problem with these:

In FileDirectoryTests>>tearDown, there is a call to 
FileDirectoryTests>>testDeleteDirectory. However, since this isn't 
called in the scope of the proper handlers, SUnit leaks exceptions.

You should never use assert: and friends outside an actual test.

I'd do the following:

FileDirectoryTests>>tearDown
	self deleteDirectory 

FileDirectoryTests>>deleteDirectory
	(self myDirectory exists) ifTrue: [
		self myDirectory containingDirectory deleteDirectory: self 
myLocalDirectoryName ].

This is still sensitive, though, to errors in the deleteDirectory: 
call (which was our problem in the first case):

BlockContext(Object)>>error:
BlockContext>>valueWithArguments:
BlockContext>>value
MethodContext(ContextPart)>>unwindTo:
Error(Exception)>>return:
Error(Exception)>>sunitExitWith:
[] in TestResult>>runCase:
Error(Exception)>>handlerAction
Error(Exception)>>signal
Error(Exception)>>signal:
UnixFileDirectory(Object)>>error:
UnixFileDirectory(Object)>>primitiveFailed
UnixFileDirectory(FileDirectory)>>primDeleteDirectory:
UnixFileDirectory(FileDirectory)>>deleteDirectory:
FileDirectoryTests>>deleteDirectory
FileDirectoryTests>>tearDown

OK, let's wrap our tearDown inside an exception handler:

tearDown
	[ self deleteDirectory ] on: Error do: [ :ex | ]

Now we don't get leaking exceptions.
Still, we have three failing tests.
These are testDeleteDirectory and two others (testExists and 
testDirectoryExists) that call it.

Why is deleteDirectory failing?

The first line makes the directory. It works fine.
	self assert: self myAssuredDirectory exists.

The second line deletes the directory. It works fine.
	self myDirectory containingDirectory deleteDirectory: self 
myLocalDirectoryName.

So the problem is here:
	self shouldnt: [self myDirectory exists]

In fact, in the debugger I see that " self myDirectory exists" answers 
true when it shouldn't.

Why?

Hmm... this is another method that was changed between 3.2 and 3.4a 
(in CS 4992).

FileDirectory>>
exists
	| result |
	result _ self primLookupEntryIn: pathName index: 0.
	^result notNil and: [result ~= #badDirectoryPath]

Ok, the prim answers
#('' 0 0 false 0)

when called on the nonexistent directory
'/home/ned/Squeak/3.4/zTestDir'

and I have no idea what that means.

Looking at the source of the prim, I see that this is trying to read 
the first index in the directory, and is expecting it to fail or 
return nil for a nonexistent directory.

However, we're not getting nil or failure here.

In fact, the answer we're getting (according to the comment) is that 
the 0th entry in this nonexistent directory is:
* named ''
* was never created
* was never modified
* is not a directory
* and is 0 bytes.

Clearly, the FilePlugin's method #primitiveDirectoryLookup is lying to 
us. But we can code around it for now:

FileDirectory>>
exists
	| result |
	result _ self primLookupEntryIn: pathName index: 0.
	^result isCollection and: [ result fourth ].

My first attempt looked for the name being non-empty. However, it 
seems that this always returns an empty string (why?) so this version 
just looks for the 0th entry being a directory. This is true on Unix, 
at least, since the 0th entry is typically "." or the directory 
itself.

I don't like this much; it seems like the FilePlugin needs to be 
fixed. Still, this seems to work (for me, under Linux).

Now all the tests succeed.

Anyone want to fix the FilePlugin or explain this behavior?
-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE