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.
Summary: | IOExeption thrown if nb user dir is imported | ||
---|---|---|---|
Product: | platform | Reporter: | Jan Pokorsky <jpokorsky> |
Component: | -- Other -- | Assignee: | _ ttran <ttran> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | isaoyanagimachi, jchalupa, mgarrison, ttran |
Priority: | P2 | ||
Version: | 3.x | ||
Hardware: | Other | ||
OS: | OpenVMS | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
IOException stack trace
patch for the broken import for OpenVMS platform isao's patch converted to unified diff |
Description
Jan Pokorsky
2001-12-07 14:26:56 UTC
Created attachment 3734 [details]
IOException stack trace
Upgrade from older version of IDE is done before the modules are loaded, that's why some attributes can be unaccessible (their value needs module specific class). Now, attributes are transfered as plain files and their values aren't resolved. fixed in release33 Verified rev#1.11.4.1 of CopyUtil. This fix breaks the Import operation on NB 3.3.1 OpenVMS. Because of a file system restriction on OpenVMS, we had to apply the patch so that "_nbattrs." is used instead of ".nbattrs" for NB 3.2.1. However,with the changes in OpenVMS JVM, we now can afford to use ".nbattrs" on NB 3.3.1. To apply this change, we added the OpenVMS specific code in org.openide.filesystems.DefaultAttributes which will rename the "_nbattrs." into ".nbattrs" (issue 18368). This change, however, became nullified in org.netbeans.core.upgrade.CopyUtil because of the AttrslessLocalFileSystem it introduced. The AttrslessLocalFileSystem overrides the LocalFileSystem's attribute operations which is what it is supposed to do. But at the same time, it also overrides the LocalFileSystem's intended list operations which use the DefaultAttributes. This ignores the code we put it to change "_nbattrs." into ".nbattrs", and causes a problem during Import on NB 3.3.1 OpenVMS. This fix breaks the patch we made in the issue 18368. The patch we made in the issue 18368 also needs to be reflected to this issue 18455 so that the OpenVMS specific .nbattrs conversion also happens here. Is there any chance that NetBeans 3.3.2 be released with this fix in it ? Thanks Isao Yanagimachi Compaq Computer Corporation I am sorry, but I don't understand how this fix breaks your patches. AttrslessLoaclFileSystem is used *only* when moving content of userdir used in previous version of IDE to the new one and it is done before starting anything else in IDE. The default filesystem which operates on imported userdir consists from o.o.f.LocalFileSystem(s) so patched version of DefaultAttributes is active. What kind of problems do you experience while importing to 3.3.1? Hi, here is what I found. In the org.netbeans.core.upgrade.CopyUtil.recursiveCopyWithFilter() method, the list of all the files (including the nbattr file) in the 3.2.1 user directory is copied over to the new 3.3.1 user directory without any filtering. The problem is that 3.2.1 user directory contains the file "_nbattrs." on OpenVMS. This file is expected be renamed into ".nbattrs" through DefaultAttributes. However since DefaultAttributes is not active during the import on NB 3.3.1, recursiveCopyWithFilter() will attempt to copy the "_nbattrs." into the 3.3.1 user directory. This operation is bound to fail because of the "." at the end of the "_nbattrs.". This is because the FileObject will think that "_nbattrs." is a file without an extension, and try to find the "_nbattrs" instead of "_nbattrs." upon the execution of the following code in the recursiveCopyWithFilter() : subTargetFo = FileUtil.copyFile (subSourceFo, dest, subSourceFo.getName ()); The code above will throw an exception because there is no "_nbattrs" in the directory. This problem did not occur on NB 3.3.0 because OpenVMS patch in DefaultAttributes renamed the "_nbattrs." into ".nbattrs". Thanks Isao Yanagimachi Compaq Computer Corporation This problem is of great concern to us (Compaq). We cannot release NetBeans 3.3.? on OpenVMS until we resolve this issue. Is there a chance there will be a 3.3.2 release, or should we build our own "patched" version of NetBeans 3.3.1 to make available to our customers? Note, building our own "patched version" something we would *really like to avoid*. For our planning purposes, we need an answer to this question quickly. Meg and Isao, this is a tricky issue. One one hand, I understand this is a significant problem for OpenVMS users, perhaps even showstopper. On the other hand, I am not sure if this fix alone would be enough to qualify for another bug fix release. I suggest you to open this issue on nbdev. Technically it's not hard to just fix this bug, make a new build and release it as 3.3.2 or 3.3.1_01. However the decision touches a few important questions regarding the way we run the NetBeans opensource project, mostly its decision-making process. [BTW, if we fix this bug, how confident do you guys at Compaq/OpenVMS feel that there won't be any other showstopper found a day after 3.3.2 (or 3.3.1_01) is released?] Thanks for the quick answer Trung. We feel pretty confident that another showstopper won't show up. We neglected to test the project import function after 3.3.0...we won't make that mistake again! Thanks for consideration, and I understand your comments about how the project is run, etc.. It's an interesting project management problem. Clearly, OpenVMS does not have the customer base of, say, Windows. (We've had 200-300 downloads from our Compaq website) And, of course, if this problem was on Windows or Linux you would be making a 3.3.1_01. But because this is an open source project, you want to be as inclusive as possible, but not to the detriment of the rest of the platforms. Tough decision. For us, we're just concerned with our customer's experience. I'll take this to nbdev... Thanks, Meg Vita, please fix this at least for CVS trunk Hi, Currently we (OpenVMS NetBeans team) are working on a patch for this problem. We will submit the patch once it is done. Thanks Isao Yanagimachi Compaq Computer Corporation May I add the 3.3.2_CANDIDATE keyword to this bug? I think the procedure would be to submit patch, I will integrate it, run our tests and mark it as 3.3.2_CANDIDATE. Well, procedure was changed, marking as 3.3.2_CANDIDATE. Created attachment 4816 [details]
patch for the broken import for OpenVMS platform
I'll deal with the patch Created attachment 4861 [details]
isao's patch converted to unified diff
Isao, please please please next time always use unified or context diff to prepare the patch. Something like cd nb_all cvs -u diff core openide > mypatch.diff The default diff is human unreadable and is not safe for the patch utility. There is very nice write up about this on http://www.netbeans.org/contrib-patches.html Patch integrated into CVS trunk. Target milestone currently set to 3.4, when we merge the fix into 3.3.2 it will be set to 3.3.2. For obvious reasons I could not verify the fix :-) Hi, Thank you for applying the patch, and my apologies for not using unified diff. Isao This bug will not be fixed in the FFJ 4.0 release. Hi, Could someone explain to me why this bug won't make it to FFJ 4.0 ? Thanks /Isao FFJ will be not supported on OpenVMS, so this P2 bug is not applicable to the FFJ 4.0 release. I'm changing the keyword to NOFFJ40 (read - doesn't affect FFJ). Please note that it still remains as a candidate for fixing in the next bugfix release of NetBeans. patch integrated into orion_fcs branch Resolved for 3.4.x or earlier, no new info since then -> verified. Resolved for 3.4.x or earlier, no new info since then -> closing. |