From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23567 invoked by alias); 19 Apr 2006 18:39:13 -0000 Received: (qmail 23552 invoked by uid 48); 19 Apr 2006 18:39:13 -0000 Date: Wed, 19 Apr 2006 18:39:00 -0000 Message-ID: <20060419183913.23551.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug classpath/27163] FTP directory listing doesn't work In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "tromey at gcc dot gnu dot org" Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2006-q2/txt/msg00122.txt.bz2 List-Id: ------- Comment #1 from tromey at gcc dot gnu dot org 2006-04-19 18:39 ------- I spent some time looking into this bug today. I am not certain that it is a bug, but I'm also not convinced that it isn't. I tracked it down to the ftp data socket's available() method returning 0. This causes the 'file.ready()' condition on the loop to return false. The test case does work for me on occasion... if the timing is right, data will be available on the socket for reading, and the ready() test will succeed. If this is a bug it is a rather obscure one, as in, perhaps the ftp code should ensure that some bytes are available before returning the input stream. It is probably more usual for loops like this to simply call readLine and then break out if it returns null. When I change the test case to do this, it works all the time. I only see the exception with gij 4.1 (not trunk) and the gcc.gnu.org site. I haven't looked into this yet. -- tromey at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tromey at gcc dot gnu dot | |org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|0000-00-00 00:00:00 |2006-04-19 18:39:12 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27163