Comment 1 Kentarou Fukuda 2009-08-12 11:05:50 EDT

Is this for ECF?

Comment 2 Scott Lewis 2009-08-12 11:24:52 EDT

This error looks to be initiated because of some problem writing to local disk when transfer data are received (i.e. the write error IOException).  Therefore, I wouldn't consider this an ECF filetransfer problem but rather some other problem on this local system that is preventing received data from being written to disk.

I don't know who to reassign this to, so I won't reassign, but if not reassigned somewhere else I'll need to resolve as invalid.

Comment 3 Prakash Rangaraj 2009-08-14 01:40:30 EDT

(*) Is it consistently reproducible? Even on a fresh install & new workspace? 
(*) Are you installing to a location where you don't have write access/disconnected network drive?

Most probably this might an error due to that. Since ECF is directly writing to the disk, I don't think IDE or even Resources component will be the right one for this bug.

Comment 4 Scott Lewis 2009-08-14 01:48:59 EDT

(In reply to comment #3)
> (*) Is it consistently reproducible? Even on a fresh install & new workspace? 
> (*) Are you installing to a location where you don't have write
> access/disconnected network drive?
> 
> Most probably this might an error due to that. Since ECF is directly writing to
> the disk, I don't think IDE or even Resources component will be the right one
> for this bug.

ECF doesn't write directly to disk.  What ECF does is write to an OutputStream provided/specified by the client (in this case p2).  So p2 is passing a FileOutputStream to ECF and this is failing to write.

The question still remaining in my mind is why is the writeError occuring on the FileOutputStream?  Is this being run in some environment where writing to disk is impossible for some reason?  (i.e disk full, no write access, etc)?

p2 depends upon having the ability to write received data to disk as FileOutputStreams.  ECF doesn't require that this be done (writing to disk for received data), but p2 does require it.

Comment 5 Prakash Rangaraj 2009-08-14 03:38:42 EDT

(In reply to comment #4)
> The question still remaining in my mind is why is the writeError occuring on
> the FileOutputStream?  Is this being run in some environment where writing to
> disk is impossible for some reason?  (i.e disk full, no write access, etc)?

    I believe so. For example Eclipse was unzipped by someone with write access into a shared folder and then someone with read-only access try to install additional components?

> ECF doesn't write directly to disk.  What ECF does is write to an OutputStream
> provided/specified by the client (in this case p2).  So p2 is passing a
> FileOutputStream to ECF and this is failing to write.

    Lets assign to P2 for comments

Comment 6 Marcel 2009-08-14 05:35:38 EDT

I had all admin right an Eclipse was a new installed with a old workspace selected, but now i removed it from the system and installed the classic SDK and load after the PDT plugin.

Comment 7 Henrik Lindberg 2009-08-14 06:08:11 EDT

(In reply to comment #5)
> (In reply to comment #4)
> > The question still remaining in my mind is why is the writeError occuring on
> > the FileOutputStream?  Is this being run in some environment where writing to
> > disk is impossible for some reason?  (i.e disk full, no write access, etc)?
> 
>     I believe so. For example Eclipse was unzipped by someone with write access
> into a shared folder and then someone with read-only access try to install
> additional components?
> 
> > ECF doesn't write directly to disk.  What ECF does is write to an OutputStream
> > provided/specified by the client (in this case p2).  So p2 is passing a
> > FileOutputStream to ECF and this is failing to write.
> 
>     Lets assign to P2 for comments
> 

(In reply to comment #5)
> (In reply to comment #4)
> > The question still remaining in my mind is why is the writeError occuring on
> > the FileOutputStream?  Is this being run in some environment where writing to
> > disk is impossible for some reason?  (i.e disk full, no write access, etc)?
> 
>     I believe so. For example Eclipse was unzipped by someone with write access
> into a shared folder and then someone with read-only access try to install
> additional components?
> 
yes, then you would see issues like this.

> > ECF doesn't write directly to disk.  What ECF does is write to an OutputStream
> > provided/specified by the client (in this case p2).  So p2 is passing a
> > FileOutputStream to ECF and this is failing to write.
> 
>     Lets assign to P2 for comments
> 
The issue could also be caused by cancelation done on a separate thread, the
file handle can then be closed while data is being received. But it did not
sound like that was the issue here.
So, check permissions, available disk space, existing file blocked by some other process, etc.

Comment 8 John Arthorne 2009-08-14 10:30:08 EDT

Yes, from my testing on this, "write error" occurs when the stream has been closed concurrently by another thread. I think you would get a different exception if it was a file permission problem (wouldn't be able to open the stream). This looks very similar to bug 277015 and bug 281430.

Comment 9 Scott Lewis 2009-08-14 12:39:25 EDT

(In reply to comment #8)
> Yes, from my testing on this, "write error" occurs when the stream has been
> closed concurrently by another thread. I think you would get a different
> exception if it was a file permission problem (wouldn't be able to open the
> stream). This looks very similar to bug 277015 and bug 281430.
> 

I don't see in the description any indication that this issue was initiated by cancellation or other multithread activity...although of course it's still possible.  Also, it looks from the description that it's not just logging the exception in this case (i.e. as in bug 277015), but rather showing it in ui/dialog.

Marcel...can this problem be reproduced?  Does it happen every time, or does it sometimes not happen (e.g. with other repos, etc)?  Does the error you describe just show in the log, or does it also show in the UI?

Comment 10 Marcel 2009-08-17 05:09:55 EDT

@scott
In the sdk version worked the pluging install routine mostly perfect, but some plugins need many time to calculate (babel).

Comment 11 Scott Lewis 2009-08-17 10:37:51 EDT

(In reply to comment #10)
> @scott
> In the sdk version worked the pluging install routine mostly perfect, but some
> plugins need many time to calculate (babel).
> 

Hi Marcel.  I'm confused by this.  So could you please summarize:  Are you able to reproduce this error at all?  If so, what steps do you need to go through to have it occur?

Comment 12 Marcel 2009-08-17 10:48:46 EDT

Currently I have doesnt the above error.

My steps was until the error:
- Starting eclipse,
- go to menu->help->install new software
- than select a option and choise a plugin and click next, now will eclipse calculate the download or so. Here openend than the small error window with a message (see above).

Comment 13 Pascal Rapicault 2009-09-02 13:53:03 EDT

*** Bug 281430 has been marked as a duplicate of this bug. ***

Comment 14 Pascal Rapicault 2009-09-25 11:05:05 EDT

*** Bug 290279 has been marked as a duplicate of this bug. ***

Comment 15 Oliver Wong 2009-09-25 11:30:49 EDT

I just want to chime in here with my experience in this bug (I submitted a bug that was marked a duplicate of this one).

1) I haven't tried reproducing it yet (don't have the time to set up a new environment).

2) The disk is not full, and I have full write access to the plugins directory, which is where I assume the IO operations are occuring. I didn't get this error for EVERY plugin I installed, only some of them. So clearly, I am able to write to the directory.

3) It's not simply an error logged in the error view, but a GUI dialog pops up, telling me that there was an error, and provides a link to the error view, which is how I was able to get the stack trace.

Comment 16 Pascal Rapicault 2009-10-20 13:07:46 EDT

*** Bug 292757 has been marked as a duplicate of this bug. ***