Well the rate of change in the file i/o plugin is rather glacial.
The write code on unix systems is below, you'll note the magic,
"lastOp", "position" and a seek or two to ensure where you
thought you wrote to, is where you wrote to. Also setSize() is busy
updating the file size, which later fools you if you are reading
from a shared file because you don't actually ask for the real file
size, you get back the size we think it was in the past.
However the fwrite() does return the bytes written and there is a
check to see if it matches expectations, and
if not this it setups the primitive call to fail. So if the write
failed it would run the primitive failure call smalltalk code
what that does, or who handles the exception raised if any, I have no
idea...
size_t sqFileWriteFromAt(SQFile *f, size_t count, char*
byteArrayIndex, size_t startIndex) {
/* Write count bytes to the given writable file starting at startIndex
in the given byteArray. (See comment in sqFileReadIntoAt for
interpretation
of byteArray and startIndex).
*/
char *src;
size_t bytesWritten;
squeakFileOffsetType position;
FILE *file;
if (!(sqFileValid(f) && f->writable)) return interpreterProxy->success
(false);
file= getFile(f);
if (f->lastOp == READ_OP) fseek(file, 0, SEEK_CUR); /* seek between
reading and writing */
src = byteArrayIndex + startIndex;
bytesWritten = fwrite(src, 1, count, file);
position = ftell(file);
if (position > getSize(f)) {
setSize(f, position); /* update file size */
}
if (bytesWritten != count) {
interpreterProxy->success(false);
}
f->lastOp = WRITE_OP;
return bytesWritten;
}
On 2009-10-23, at 12:43 PM, Schwab,Wilhelm K wrote:
> John,
>
> That sounds badly, badly, broken. Is it "only" #flush that suffers,
> or will any of the I/O fail silently?
>
> Bill
>
>
>
> -----Original Message-----
> From: [email protected] [mailto:pharo-
> [email protected]] On Behalf Of John M McIntosh
> Sent: Friday, October 23, 2009 1:57 PM
> To: [email protected]
> Subject: Re: [Pharo-project] Shared directories: The bug is quicker
> than the eye
>
> If you invoke the flush primitive then it does this on unix/linux/
> mac- osx/iPhone
> http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/fflush.3.html
> &
> http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man2/write.2.html#//apple_ref/doc/man/2/write
>
> sqInt sqFileFlush(SQFile *f) {
> /* Return the length of the given file. */
>
> if (!sqFileValid(f)) return interpreterProxy->success(false);
> fflush(getFile(f));
> return 1;
> }
>
> On windows it does
> http://msdn.microsoft.com/en-us/library/aa364439(VS.85).aspx
>
> sqInt sqFileFlush(SQFile *f) {
> if (!sqFileValid(f)) FAIL();
> /* note: ignores the return value in case of read-only access */
> FlushFileBuffers(FILE_HANDLE(f));
> return 1;
> }
>
> I'll note the api doesn't actually check for errors, give feedback
> or whatever.
> *cough* it could be failing and give you a clue, but you would need
> to resort to FFI to do the file system calls to get the data to
> visualize, or build your own VM with that returns the result.
>
>
>
> On 2009-10-22, at 5:31 PM, Schwab,Wilhelm K wrote:
>
>> Hello all,
>>
>> I'm not sure what to make of this one. I just spent a couple of
>> hours
>> trying to find the "leak" in an algorithm of mine. It was reading
>> roughly 1200 records, claiming to have processed all of
>> them, and yet writing only about 450 rows into an output text file.
>> One clue should have been that the number of output rows was somewhat
>> random; I did not fully appreciate that until I worked around the
>> problme.
>>
>> I tried an explicit #flush - no help. I looked for logic errors and
>> found none. The file was being written to a Windows hosted share
>> mounted by CIFS (which I am learning to view with contempt) from
>> Ubuntu 9.04. You can see where this is going: writing the file
>> locally gave the expected result.
>>
>> Any ideas on how one might further isolate the problem? My trust in
>> Windows is well known<g>; I have never liked shared directories; I
>> _really_ do not like CIFS as compared (reliability wise) to SMBFS;
>> the
>> network between me and the server is in question too (long story).
>> All of that said, file support in Squeak, and hence so far inherited
>> by Pharo, is not the best code I have seen to date, so it is easy to
>> suspect too. Can one argue that since it worked locally, Pharo is
>> not
>> the problem?
>>
>> The little bit that I know of cifs is not encouraging. It sounds as
>> though things moved from an easily killed process into the kernel
>> which shows an almost Windows-like unwillingness to shut down when it
>> cannot see servers. I have found numerous reports of problems
>> copying
>> large files over cifs, and I have enountered them too.
>>
>> Bill
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> =
> =
> =
> =
> =
> ======================================================================
> John M. McIntosh <[email protected]> Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd. http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
=
=
=
========================================================================
John M. McIntosh <[email protected]> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
