Here's something to make you scratch your head. When would the #size of aStandardFileStream ever change merely by closing and then opening the file?
myFileStream size "3300"
myFileStream close; open
myFileStream size "50"
Ok, don't scratch; I've already done that. The answer is when you #truncate: to 50 the file, it is not reflected by #size until the file is closed and reopened.
It's #position does recognize the truncation however, if it was beyond the truncation point of the now-shorter file, it reflects position at the end of the file. This is my first time exploring truncate: so I don't now whether this is a bug. But I've opened it on Mantis just in case.
It does appear to actually shorten the file and release the space back to the OS; is this platform-independent?
Chris Muller chris@funkyobjects.org wrote:
Here's something to make you scratch your head. When would the #size of aStandardFileStream ever change merely by closing and then opening the file?
myFileStream size "3300"
myFileStream close; open
myFileStream size "50"
Ok, don't scratch; I've already done that. The answer is when you #truncate: to 50 the file, it is not reflected by #size until the file is closed and reopened.
This is a side effect of the fairly poor implementation of the file accessing prims from all the way back. I'm pretty sure I've whinged about it before, probably several times.
The sensible answer is a complete rewrite of the entire file system codebase along with the directory and file naming cesspits. Maybe someday...
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Useful random insult:- Mouth is in gear, brain is in neutral.
On 6/3/05, Chris Muller chris@funkyobjects.org wrote:
Here's something to make you scratch your head. When would the #size of aStandardFileStream ever change merely by closing and then opening the file?
myFileStream size "3300" myFileStream close; open myFileStream size "50"
Ok, don't scratch; I've already done that. The answer is when you #truncate: to 50 the file, it is not reflected by #size until the file is closed and reopened.
Hi Chris,
#size is generally unreliable - you can see the same effect if you use another FileStream instance to append to the end of the file, for example. I had to modify OmniBase so that whenever the database needs to know the size of the file it opens a readOnlyCopy, sends #size, and immediately closes it. Luckily this only needs to happen once per commit and so the extra time this takes is ok.
This is only an issue on unix, btw - the Windows VM gets this right.
Avi
Avi Bryant avi.bryant@gmail.com wrote:
This is only an issue on unix, btw - the Windows VM gets this right.
Not entirely true - I think Macs would have the same problem since they appear to use the 'portable' sqFilePluginBasicPrims.c code. And RISC OS has quite different code but I carefully made it do the same things 'wrong' to maintain compatability as closely as possible.
There is just so much wrong down there it hardly bears thinking about. Just as an example relating to truncate - what if two places have the same file open and one of them truncates? What happens on OS 'X' if you write to a position beyond the supposed file end? Or try to read?
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Useful random insult:- Result of a first cousin marriage.
Test cases come to mind, I"ve that file test SUnit about, remember the one where file open/locking behavior is different between os-x and os-9.
On Jun 3, 2005, at 12:10 PM, Tim Rowledge wrote:
Avi Bryant avi.bryant@gmail.com wrote:
This is only an issue on unix, btw - the Windows VM gets this right.
Not entirely true - I think Macs would have the same problem since they appear to use the 'portable' sqFilePluginBasicPrims.c code. And RISC OS has quite different code but I carefully made it do the same things 'wrong' to maintain compatability as closely as possible.
There is just so much wrong down there it hardly bears thinking about. Just as an example relating to truncate - what if two places have the same file open and one of them truncates? What happens on OS 'X' if you write to a position beyond the supposed file end? Or try to read?
tim
Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Useful random insult:- Result of a first cousin marriage.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
squeak-dev@lists.squeakfoundation.org