David T. Lewis wrote:
> On Wed, Feb 25, 2004 at 06:38:58PM -0800, Julian Fitzell wrote:
> 
>>I've encountered a problem, while using OmniBase, in that squeak returns 
>>an incorrect file size if the size has changed since it was opened. 
>>This appears to be because the file size is returned from a 
>>rarely-updated file structure.  I have solved this by changing 
>>sqFileSize() to get a file descriptor with "fileno(f->file)" and then 
>>using fstat() to get the file size.
>>
>>There are several other references to f->fileSize which I think could be 
>>replaced with calls to the new and improved sqFileSize() (or this could 
>>be pulled out into another helper I guess...
>>
>>Does anyone see any reason why this shouldn't work this way?  Is it too 
>>slow in some case or something?  I guess fstat() isn't ANSI-compliant... 
>>how much does that matter compared to returning an incorrect value?
>>
>>I guess my questions are two-fold:
>>
>>1) Is there some reason I shouldn't be doing this in my own VM?
>>2) Should I be preparing this to submit as a fix?
>>
>>Julian
> 
> 
> See DirectoryPlugin on Squeak Map, which provides a stat(2) call. Ian's
> VM distribution includes the precompiled plugin, and if you load DirectoryPlugin
> source from Squeak Map, there is an example class side method #stat that
> does what you want. For example the size of file '/etc/hosts' is answered by:
> 
> 	(DirectoryPlugin stat: '/etc/hosts') at: 5
> 
> or equivalently by:
> 
> 	(DirectoryPlugin getEntry: '/etc/hosts') fileSize
> 
> I believe that this works correctly on Windows also, although it would be
> inconvenient to reboot and confirm it right now ;-)

Hmm... well that's certainly another option, but I don't think that 
excuses us from having a file size primitive that returns an incorrect 
answer... does it?  (wondering only because maybe there's some reason 
why you'd rather have the file size when you opened the file?  can't 
really think of one...)

Julian