🚀 go-pugleaf

Hi there,

I do use a function that takes a Win32 string, parses it and replaces
single backslash characters with double backslashes. So that's not the
problem.

I've somewhat solved this "Bad file descriptor" temporarily at least.
You see I was splitting the procedure in two. I would create the File
object and the FileInputStream object in a procedure called uploadFile()
in one class, and within it, call a worker thread that finished the job
where in its run() method would execute the while loop.  The worker
thread gets a reference to the FileInputStream object and the
DataOutputStream object.

For some reason, when I split things up this way it generates this "Bad
file descriptor" error.  I still don't know why that is.

Anyway, for the sake of expediency, I've cut out the use of the worker
thread for now and have placed all the code in the uploadFile() method.
Now, I don't get the "Bad file descriptor" error.

However, now I'm faced with a new dilemma. The while loop is working at
both ends except that the condition never exits the loop.  I have an
endless loop condition.  I've tried:

while((n = FileIn.read(buffer)) >= 0)

and

while((n = FileIn.read(buffer)) != -1)

Both are endless.

Any suggestions?

Alan  

Owen Green wrote:
> 
> "Alan Shiers" <ashiers@hfx.eastlink.ca> wrote in message
> news:3D226288.1C7C905@hfx.eastlink.ca...
> > Hi guys,
> >
> > I've been busy trying to implement the new code and I'm having a problem
> > with the conditional statement of the while loop.
> >
> > myFile = new File("C:\somepath\somefile");
> > if(myFile.exists())System.out.println("file exists");
> > FileIn = new FileInputStream(myFile);
> >
> > byte[] buffer = new byte[128];
> > int n;
> > while((n = FileIn.read(buffer)) >= 0)  << Problem line
> > {
> >     rq.output.write(buffer);
> > }
> >
> > The FileIn object is a FileInputStream object and everytime at runtime I
> > get an IOException stating that it has a "Bad file descriptor".  I don't
> > understand what it is telling me or how to fix it.
> >
> > Earlier, I had created a File object using an absolute file path and
> > file name. Even tested it with the File.exists() method, which returned
> > true, and used the File object as an arguement for the FileInputStream
> > object, like so: FileIn = new FileInputStream(myFile);
> 
> Isn't that exactly what you've shown above?
> 
> > What is causing this "Bad file descriptor" thing?
> 
> I'm not sure :) It could be
> a) That it doesn't understand what you're asking it; are you really writing
> win32 paths as "c:\blah\blah" as oppossed to "c:\\blah\\blah" or
> "c:/blah/blah"?
> b) There are a limited number of FD's available, afaik, do you have lots
> open at any one time? (this includes sockets, btw).