You mentioned you were testing on Linux, I wonder have you reproduced this on any other platforms?
I don't have any other ones *convenient* to test upon right now, but will give it a try when I can. Would be good to know...
You have only found this to be a problem with writing to SocketChannels is that right?
Have you confirmed that the FF data is necessary to make this happen?
Yes. It only happens in that one file, which is a GIF which happens to have 3 consecutive FF's.
Zeroing the first FF makes the bug go away entirely (i.e. 2 FF's is fine, it's having three that causes two bytes to be lost)
Curiously enough I was using transferTo for a file copy and found it's performance to be a bit slower than expected.. I was going to just leave it as is, but this report has me a bit concerned that perhaps I should stick to the 'old way'?
Note that I have *no workaround* for this bug!
Also note that *there is no way of detecting the bug in your own code*! (because in their infinite wisdom the sun staff implementing NIO didn't provide any way to examine the state of a channel). The first time you learn of it will be when some important file has been corrupted. Not good.
I am beginning to wonder to what extent sun's NIO staff deliberately broke NIO on windows and linux. NB: what follows is tongue-in-cheek...
Bear in mind that for the first 2 years after gold release NIO didn't work on windows. Ultra basic stuff like being unable to have more than 64 clients (WTF!), and selectors that didn't select (!). LIkewise, Sun's linux implementation of NIO did ultra-stupid stuff like using the only form of nb/asynch I/O on linux that no-one ever uses because it's so crap. Plus all the show-stopping bugs that hung around for > 1.5 years after *gold* release.
Oh, yeah, and the fact that they still haven't written any documentation explaining how to use NIO.
Browsing NIO bug reports today, I noticed an alarming number with "closed, wontfix, couldnt reproduce" with multiple "I get this problem too" comments from different users over the course of a year or more. Having had a bug rejected once before by a sun engineer too lazy to investigate my bug, I know what it feels like (NB: just to be clear, I've had circa 20 bugs logged with sun engineers, most of whom were very helpful, some going way beyond what they needed to do in order to try and help fix the problem - I've only had the one particularly bad experience)
Makes you wonder, no?