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.