Using Jruby 1.7.8 deployed in a Tomcat7 container (warbled war) - I have created a demonstration project
I have not recreated the issue but have isolated and observed it in my application code.
Using the "spreadsheet" gem in Windows relies on the Ruby-OLE gem. This gem was returning a IOError exception on a @io.rewind statement. @io is a File object.
Bisecting the issue I have narrowed it down to immediately prior to the @io.rewind is a @io.size > 0 test. If this is changed to @io.stat.size > 0 then the code proceeds. This suggests that the RubyFile size method irritates an (probably Windows) issue that damages the underlying file handle.
How do you feel about using the same approach as with "ctime" or "atime"? i.e. context.runtime.newFileStat vs runtime.getPosix().fstat ... just a thought.
I have created a project that demonstrates is issue at https://github.com/jayjlawrence/jruby-File.size
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
Windows 2008 R2 64 bit in a VMware VM
Edited the original report - note that I have created a project that exposes this issue at https://github.com/jayjlawrence/jruby-File.size
Ouch I can see what is wrong....
This is getting called unconditionally and is closing the same descriptor that win32ole impl must be using. Another wrinkle in this is that I cannot reproduce #770 which is using the same method on 1.7 branch currently so fixing the close issue most likely might still mean there is something wacky with this impl. We enabled real native errors a while back for syscalls on windows and keep getting really weird exceptions back for uncommon values. Enough rambling. I at least know your core issue...
Fixes #1272 and hopefully #770
So I took your advice and added a windows path to impl size like we do atime/ctime, but this is non-optimal and so I added a FIXME. The truth is our fstat impl in jnr-posix is broken in two ways:
An update to confirm that the fix appears to work. I pulled the commit into 1.7.8 and ran code that uses filehandle.size quite extensively. THANKS for the amazing turnaround on this one.