Re: filesize error
- Posted by CoJaBo2 Dec 03, 2012
- 1872 views
I posted a simplified case (needs no input files) here- http://openeuphoria.org/pastey/174.wc
Ticket here- http://openeuphoria.org/ticket/825.wc
It works under 4.0.4 on 32-bit Linux; looks like a bug specific to Windows version of Eu.
I suspect it won't make a difference, but has anyone tried 4.0.5 ?
Another thing to try would be a MinGW build of 4.0
I jumped from v4.0.4 to v4.1.0.Nov28 because of the leak fixes in the latter.
I was just looking for additional data points that could narrow the cause of the issue.
I updated the ticket-
This now appears to be a result of disk corruption; it works for me in 4.0.4 and 4.0.5, unless_ can't reproduce it either (and it sometimes seems to be creating files of negative sizes).
The display of the filesize is not causing a filesize. Neither is the bad display of filesize causing a bad filesize. When the filesize is being limited to 2^32, it doesn't matter that is being shown, the filesize is unchangingly stable at 2^32.
The error in display is shown in
http://designerthinking.com/images/NEGSIZE1.JPG
http://designerthinking.com/images/NEGSIZE2.JPG
and is NOT the individual filesize on the left, which is correct, but the folder total, which i have placed a red arrow on. There is pattern of clicks to cause the size display error, if i do not click on a file which has a size over 2^32, then Explorer makes no error in the display. Either way, the individual size on the left is correct.
That said, twice today v4.0.4 eui and euiw failed, and twice today both wrote files over 2^32. I do not know what is going on. Eu v4.1.0.Nov28 has not failed in any filesize test.
useless
Are you able to check the disks involved for errors? Ideally, both with scandisk/chkdisk and smartctl. It might also serve to do a memory test.
There is no reason Windows should ever be reporting negative sizes, unless something is severely broken somewhere.
Checking SCM, it does not appear that any of the code involving file output has changed between 4.0.4 and 4.1.0. I.e., there should be no reason whatsoever why 4.1.0 would work and 4.0.4 would not. And, there is certainly no reason why such a problem would occur only some of the time, outside of filesystem curruption and/or hardware failures.
