jruby
jruby copied to clipboard
File.open w/ File::RDWR should write \r\n but gets should read as \n after rewind on windows
Environment
Note: duplicated issue from #3738. This is broken differently than 1.7's version of this bug so I made a new issue to track it on 9k.
Broken on 9.0.5.0.
Expected Behavior
For the following script:
file = "temptemp"
File.open(file, "w") {}
File.open(file, File::RDWR) do |f|
f.puts("writing") # writes "writing\r\n"
f.flush # force to disk
gets # do not continue until you can verify it was written right
f.rewind # backup
p f.gets # read it but it should be "writing\n"
end
File.unlink(file)
The comments dictate how it should behave.
Actual Behavior
On JRuby 9.0.5.0 it wil write "writing\n" instead of "writing\r\n" but it will read "writing\n".
Bumping discovered windows issues from 1.7 windows work to 9.1.1.0 because we have not CI-greened 9k on appveyor yet. Next release we will have greenness.
Next release, and the one after it, still don't have greenness on Appveyor...and this is an internal report, so I guess we bump it again.
file = "temptemp"
File.open(file, "wb") { |f| f.puts("\r\n") }
File.open(file, "r") { |f| p f.gets }
File.unlink(file)
on windows it should print "\n" but it prints "\r\n"
Based on @ahorek example this is still broken on Windows. It writes crlf to the file and reads it back in as crlf. Seems like binary mode is not working properly for this case but I am confirming CRuby behavior now.
CRuby also writes CRLF to the file. The read is where it normalizes back to just LF, due to the mode not being b.
On JRuby:
- mode
wbwith a write of CRLF writes CRLF - mode
wwith a write of CRLF writes CRLF - mode
wwith a write of LF writes CRLF - more
rbwith a file containing CRLF reads CRLF - mode
rwith a file containing CRLF reads CRLF
On CRuby:
- mode
wbwith a write of CRLF writes CRLF - mode
wwith a write of CRLF writes CRLF - mode
wwith a write of LF writes CRLF - mode
rwith a file containing CRLF reads LF - mode
rbwith a file containing CRLF reads CRLF
Only the non-binary read mode seems to be in error here.
It appears at a glance that we are setting up the right newline conversions in the IO transcoding pipeline, so this one will take more stepping to see why it is not normalizing CRLF to LF on a non-binary read.
Not a critical item so punting to 9.3.1.