This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 192440 - Don't use FileOutputStream, use fileObject.getOutputStream()
Summary: Don't use FileOutputStream, use fileObject.getOutputStream()
Status: RESOLVED FIXED
Alias: None
Product: php
Classification: Unclassified
Component: FTP Support (show other bugs)
Version: 7.0
Hardware: PC Linux
: P2 normal (vote)
Assignee: Petr Pisl
URL:
Keywords:
: 193954 194975 195104 (view as bug list)
Depends on:
Blocks: 192099
  Show dependency tree
 
Reported: 2010-11-24 20:44 UTC by Jaroslav Tulach
Modified: 2011-02-28 15:09 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2010-11-24 20:44:20 UTC
There is a bug 184854 which keeps happening again and again. However most of the errors that happen there are related to PHP and its FTP support. That gave me an idea that the PHP must be doing something wrong.

Indeed it does. org.netbeans.modules.php.project.connections.RemoteClient does not access the disk via FileObject APIs, but bypasses it and uses java.io.File access directly. 

This puts the system under enormous stress. Consider rewrite to FileObject API.
Comment 1 pgebauer 2010-12-02 19:53:22 UTC
Is the problem with system stress related only to the style how the OutputStream is  obtained  or any direct usage of java.io.File object is forbidden?
Comment 2 Jaroslav Tulach 2010-12-03 15:43:02 UTC
Usage of java.io.File in NetBeans is not recommended in general.
Comment 3 Tomas Mysik 2010-12-10 19:11:05 UTC
Yes, the reason was that opened files were closed after their remote version was downloaded from server. This was the only solution we were able to think of at that time (and implement, it was just before NB 6.5 FCS). Likely there's a better way to do it, sorry.
Comment 4 pgebauer 2010-12-15 10:09:09 UTC
To Jarda: Currently the method FileUtil.refreshFor(baseLocalDir) is used for the FileSystem synchronization. Could a calling of the method FileObject.refresh() after every change of java.io.File improve the current behavior?
Comment 5 Jaroslav Tulach 2011-01-03 09:17:27 UTC
*** Bug 193954 has been marked as a duplicate of this bug. ***
Comment 6 pgebauer 2011-01-07 09:39:58 UTC
http://hg.netbeans.org/web-main/rev/1041531a0ebb
http://hg.netbeans.org/web-main/rev/290c41d94bbb

The behavior should be better now. Jardo, could you please review changes?
Comment 7 Jaroslav Tulach 2011-01-07 20:05:11 UTC
I don't see use of fileObject.getOutputStream() in the linked changesets at all! I can't confirm or decline whether the behavior is now better, but unless you are File system provider (which you are not right now), I consider it dangerous to heavily mangle with disk file structure via java.io.File.
Comment 8 Quality Engineering 2011-01-09 06:19:44 UTC
Integrated into 'main-golden', will be available in build *201101090000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/1041531a0ebb
User: PGebauer <pgebauer@netbeans.org>
Log: #192440 - Don't use FileOutputStream, use fileObject.getOutputStream()
Comment 9 Jaroslav Tulach 2011-02-07 08:36:45 UTC
*** Bug 195104 has been marked as a duplicate of this bug. ***
Comment 10 Jaroslav Tulach 2011-02-07 12:17:01 UTC
*** Bug 194975 has been marked as a duplicate of this bug. ***
Comment 11 Petr Pisl 2011-02-28 15:09:35 UTC
I have rewritten the implementation while fixing issue #195141. The change set is here: http://hg.netbeans.org/main/rev/a7d34e4aaba8

Using java.io.File was replaced with using FileObjects.