hi Thomas, Thanks for your quick reply.
Your assumption is right, foo.txt exist here when I reproduced the issue. Thanks. --- 13年3月25日，周一, Thomas E Enebo <tom.en...@gmail.com> 写道： > 发件人: Thomas E Enebo <tom.en...@gmail.com> > 主题: Re: [jruby-user] File#size returns still "Unknown Error (20047)" on > windows, right? > 收件人: u...@jruby.codehaus.org > 抄送: dev@jruby.codehaus.org > 日期: 2013年3月25日,周一,下午11:38 > I re-opened the JRUBY-4820 to make > sure we don't lose it and based on > comments it makes me wonder if it has ever fully been fixed > or not. > It is a really basic method but File.stat(file) probably > uses 'stat' > and File.size might use 'fstat' which could be some weird > posix compat > issue on Windows for us (since I have not looked at these > methods in > quite a while I will need to revisit > this). Worst case we can > special case windows and use the jnr-posix method we know > works for > Windows. Best case we solve what is wrong in jnr-posix > to properly > support this. > > The 20047 error is an interesting error because it still > would have > been a bug for you. I am assuming foo.txt exists when > you ran that. > So it should have worked...but didn't...then returned a > nonsense error > instead of the error of a ENOENT. So if you can > somehow squeeze in a > third bug into this single call it will be a trifecta :( > > Color us embarrassed.... > > -Tom > > PS- JRUBY-6136 is a difficult issue to solve in my > mind. jnr-posix is > supposed to expose posix methods and we want proper > granularity of > errno values. If we mask all the various windows > errnos we will gain > more cross-platform consistency at the cost that consumers > of > jnr-posix (jruby is not the only user of it) will lose the > specific > errnos (who am I to say knowing a mapped network drive errno > is not > what someone wants). At this point we > should capture the two weird > errnos we know about on the JRuby side as an interim > solution and > remap them to ENOENT. > > On Mon, Mar 25, 2013 at 6:52 AM, h h <netbuc...@yahoo.com.cn> > wrote: > > hi guys, > > > > I encountered an issue with File#size returning 20047 > on windows by spreadsheet gem, and I can reproduce the same > error in jirb as below: (latest jruby 1.7.3, windows 7, > jdk1.6.0_26) > > ---------------------------------- > > C:\Users\me>jirb > > irb(main):001:0> f=File.new "foo.txt" > > => #<File:foo.txt> > > irb(main):002:0> f.size > > SystemCallError: Unknown error - Unknown Error (20047) > - -1 > > from > org/jruby/RubyFile.java:1082:in `size' > > from (irb):2:in > `evaluate' > > from > org/jruby/RubyKernel.java:1066:in `eval' > > from > org/jruby/RubyKernel.java:1409:in `loop' > > from > org/jruby/RubyKernel.java:1174:in `catch' > > from > org/jruby/RubyKernel.java:1174:in `catch' > > from > C:\jruby\jruby-1.7.3\bin\jirb:13:in `(root)' > > ---------------------------------- > > > > I found two bugs in jira about this issue: > > The first one is : > > [windows] File.size is completely broken on Windows > > with the link http://jira.codehaus.org/browse/JRUBY-4820 > > the Status is "Resolved", the Resolution is "Fixed", > but Fix Version/s is "None". > > > > The second one is: > > Changing jnr-posix to use errno() value unconditionally > has created lots of failures in windows > > with the link http://jira.codehaus.org/browse/JRUBY-6136 > > the status is "Open", Resolution is "Unresolved". > > > > So, do we still have this bug in latest v1.7.3? > > I want to have a confirmation, then we can decide what > to do next? > > > > Or any workaround for this issue? > > > > Thanks. > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list, please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > > > -- > blog: http://blog.enebo.com > twitter: tom_enebo > mail: tom.en...@gmail.com > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
