Well first I thought we had broken the 64/32 file size mapping, but I  
see that the primitive does
point to a quad word (64) structure and the file browser does report my  
4TB file correctly.

Now the mac vm and the unix vm share the same source code for file  
operations since the move to 64 bit file operations back in 2001,
  the only difference is what squeakFileOffsetType is resolved to, which  
in this case I believe is the same unix type. I think what you'll
need to do here is code up a sub-method to catch  
StandardFileStream>>size being wrong.

The size comes from being set to ftell() on open after a seek to the  
end of the file. {which will be the number of bytes in the file}
 From then on either:

truncate invokes sqFTruncate() which might/should/could invoke  
ftruncate then we look at ftell() again to set filesize
{I wonder if that is correct?} Mmm I sure I got an SUnit here  
somewhere, mmm can't find it (ack). I'll look later.

sqFileWriteFromAt, after the fwrite, an ftell is done and the results  
compared to the filesize and if larger then we set filesize to the  
ftell value.

on close it gets set to zero.

if you ask the size of a closed file, I think you get a prim failed,  
but does that get caught and turned into filesize zero?
Mmm well we do a self error: 'a primitive has failed'.


Later:
  the SUnits I had to test size, truncate and write are below
If you see a fault in the testing let me know.

testFileCreateAndSeek
	| shortDir file check |
	shortDir _ self createDirectoryCalled: shortName in: FileDirectory  
default.
	file _ shortDir newFileNamed: shortFileName.
	self should: [file atEnd].
	1 to: 1024 do: [:i |
		file truncate.
		self should: [file size = 0].
		file position: i-1.
		file nextPut: $a.
		self should: [file size = i].
		file position: i-1.
		check _ file next.
		self should: [check = $a].
		file truncate: i-1.
		self should: [file size = (i-1)].
		].
	file close.
	shortDir deleteFileNamed: shortFileName ifAbsent: [self assert: false].

testFileCreateAndWrite1024
	| shortDir file string |
	shortDir _ self createDirectoryCalled: shortName in: FileDirectory  
default.
	file _ shortDir newFileNamed: shortFileName.
	string _ self get1024String.
	self should: [file atEnd].
	1 to: 1024 do: [:i |
		file truncate.
		self should: [file size = 0].
		file position: 0.
		file next: i putAll: string.
		self should: [file size = i]].
	file close.
	shortDir deleteFileNamed: shortFileName ifAbsent: [self assert: false].

On Nov 12, 2003, at 2:42 PM, Colin Putney wrote:

> Hi folks,
>
> Yes, more Panther woes.
>
> The problem is that CompiledMethod>>#timeStamp occasionally goes into  
> an infinite loop. The reason is that StandardFileStream>>#size reports  
> the wrong size for the changes file. This causes #nextChunk to return  
> empty strings without advancing the file position, which then never  
> reaches the position the loop is testing for, which means the loop  
> never exits.
>
> The only way I've been able to reproduce this is by running the  
> Monticello test suite, which just happens to be an incredible stress  
> test for just this sort of thing. It does a lot of changing methods  
> (thereby lengthening the changes file), then fetching sources, then  
> changing methodz again, all in rapid succession. At some random point  
> in the test run MC will hang while attempting to take a snapshot of  
> the mock package and eventually the ProcessBrowser will intervene  
> allowing me to debug. Recovering the test run is quite easy - all I  
> have to do is restart CompiledMethod>>#timeStamp and proceed, then all  
> is well. I suspect this is because the file is reopened at the  
> beginning of the method.
>
> It makes no difference whether I use a 3.6 or 3.7 image, nor whether I  
> run the Unix VM (3.6g-2) or the Carbon VM (3.6.1Beta2).
>
> This leaves me about to dig into the FilePlugin, where I am out of my  
> depth.
>
> Any ideas?
>
> Colin
>
>
>
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===