As this is not affecting data  I am changing priority of this bug to P2.

This is not a problem in the ClearCase profile, it's a bug in vcscore
module in the file status caching system.

Is this reproducible? It seems like the parent file of the refreshed
object is not found. So perhaps the view is directly some drive
letter?

This bug seems to be generic for all VCS profiles. If you define your
working directory as just a drive letter, this exception is thrown.
Moreover a corrupted filesystem is stored in
system/Projects/Default/system/Mount, which cause some exceptions
being thrown after restart of the IDE.

I suggest this to be P1. Any comments from QA? I've found the IDE not
to be much stable after trying to mount a letter drive.
Also it's not possible to use working directories like "D:\" not only
in ClearCase, but not in CVS as well.

It is difficult to say...

I don't think that mounting a DRIVE root is a common user scenarion
(and on Windows exist possibillity to mount a drive into a dir).
So for that reason it is not IMHO stopper.

For CC users it might be a problem 'cause AFAIK they mount root of
DRIVE....


And there is still question about affectiong data this situation:
If you try it eg. with CVS profile, then it seems corrupt your
$user_dir and to get rid of various E. you might have to delete yours
$user_dir.
This sound like a reason for making it as a showstopper
-------------------------------------------------------------

->to PCM Reddy:
Would you be so kind and write us your oppenion about common user
scenario of ClearCase user on Windows
And if then it nothing corrupt? 

Thanks
-daniel

This will happen to most of the users who uses ClearCase Dynamic
views. This is a vitual drive letter created by clearcase dynamic view
on windows. This is not a physical drive in windows box. This bug will
appear to a common user. We may need to provide a nice dialog box in
place of NPE.

Thanks,

so that sees it is showstopper for you (or CC users) :-(
Then we should increase the priority to P1...

The problem is fixed in the main trunk. The fix is simple, we must
take into account, that the parent directory may not exist:

/cvs/vcscore/src/org/netbeans/modules/vcscore/cache/CacheDir.java,v 
<--  CacheDir.java
new revision: 1.33; previous revision: 1.32
/cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCache.java,v 
<--  VcsCache.java
new revision: 1.57; previous revision: 1.56

Created attachment 9784 [details]
The context diff, that fix this problem.

Created attachment 9785 [details]
The binary patch, that fix this problem. Put into <NB-install>/modules/autoload/patches/org-netbeans-modules-vcscore/ folder.

PCM Reddy, can you please verify the issue with the attached binary
patch? Thanks.

Adding to cc Peter Wisnovsky so that he is aware of this issue.

I'll also take a look at this patch on my Win XP. But till tomorrow...

Martin, it's GREAT!
No exception, etc... and other restriction for mounting
just my DRIVE as a working.

But, I didn't satisfy just with smooth mounting, 
I also check briefly some functionality, and I found problems
in Refresh recursively and there might be possible others problem for
rest of commands....

So, my summary is:
==================
patch is good, but because of fixing this problem
I would have discovered others bugs...
I'm not going to enter new one, but rather reopening it
(if you agree:)

Reproduction:
==============

I copied a content of one my working directory to the empty 
partition labeled E:

Then I Started CVS Mounting Wizard (common for j-cvs and g-cvs)

As a working dir I chose E:\
Everything next was recognized and I only chose I wish to use cmd-line
client.

In my mounted G-CVS FS I could see just everything as it was on my
disk E:\

When I expanded nodes lots of them were [local]
So I decided to perform Refresh Recursively

And troubles begin:-(
=====================
After refresh finished, all nodes in the FS were collapsing
and recollapsing (don't know how to better describe)
But there were then at least twice more nodes in a root of FS than it
was physicaly in my drive E:\

Normal refresh on the root of FS will repair it and RefRec.
will break it again....


Here is Execution String:
cmd /X /C "cd /D \"e:\\\\.\"&&   \"C:\space\cvs\cvs.exe\" -d
\":pserver:anoncvs@fortecvs:/nbextra\" -f status -R "

I'm attaching Ref.Rec.outputs

Created attachment 9800 [details]
Output to the first Refresh

The second refresh Executing String:
org.netbeans.modules.vcs.profiles.cvsprofiles.list.CvsListRecursiveCommand.class
LIST_SUB_STATUS_CMD LIST_SUB_LOG_CMD

see following attachment of its output

Created attachment 9801 [details]
Second Refresh data-output

Oups:-///
There is another problem:
Seems that something is then corrupted in your $user_dir
You've got Es. when mounting another FS:
org.w3c.dom.DOMException: Wrong root element: brokenDocument
and
java.io.FileNotFoundException: Relative path: F: Which is printed only
into ide.log when mounting the first FS

This could never occure without this patch.

reproduction:
=============
1)
Just for aussuring the correct and reliable functionality
Mount G-CVS FS to a working dir which is not your root of a drive.
E.g.: F:\myworkingDir1\
Perform there some normal and Recursive refreshes.
Everything till now is right.

2)
Mount G-CVS FS to your root of drive. E.g: E:\
Perform normal and Recursive and normal Refresh

3)
Unmount first FS

4)
Mount G-CVS FS axactly the same way you mount first FS
When you get to the point of choosing profile and choose
one, you will get an exception:
org.w3c.dom.DOMException: Wrong root element: brokenDocument

I'm gonna attach the whole ide.log
with stacktraces of all E.

Created attachment 9808 [details]
my ide.log with FNFE & org.w3c.dom.DOMException stacktraces

At least the Refresh Recursively now works correctly. I'm still
exploring the problem with loading of VCS profiles.

/cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/list/CvsListRecursiveCommand.java,v 
<--  CvsListRecursiveCommand.java
new revision: 1.9; previous revision: 1.8

I've finally found where is the problem. On some systems (like
Windows) if you remove the last File.separator from the file path you
can corrupt the path! Like "D:\" must be kept with the last backslash,
"D:" is not a valid path.
This bug makes the whole IDE unstable, because FileUtil.toFile()
produces bad results.

/cvs/vcscore/src/org/netbeans/modules/vcscore/VcsFileSystem.java,v 
<--  VcsFileSystem.java
new revision: 1.220; previous revision: 1.219

Created attachment 9829 [details]
The whole context diff, that fix this problem.

Created attachment 9831 [details]
The binary patch for vcscore module. Put into <NB-install>/modules/autoload/org-netbeans-modules-vcscore/ folder.

Created attachment 9832 [details]
Binary patch for cvs-profile module. Put into <NB-install>/modules/patches/org-netbeans-modules-vcs-profiles-cvsprofiles/ folder.

Please test *all* CVS commands (it would be good to have also PVCS,
VSS and ClearCase commands tested) in the root of FS mounted at a
letter (e.g. "G:\") in Windows. Thanks.

The diff looks ok for me. See no problem to integrate it  after
verifying by QA.

Further check added to VcsAttributes in the main trunk:

/cvs/vcscore/src/org/netbeans/modules/vcscore/VcsAttributes.java,v 
<--  VcsAttributes.java
new revision: 1.27; previous revision: 1.26

Please let me know whether this is necessary for NB 3.5 / S1S 5.0 as
well. It checks whether the File returned from FS is absolute.
This is an add-on, that assures, that class loaders will work O.K., it
silently ignores files, that might be corrupted and can therefore
destabilize the whole IDE.

How to reproduce:
Mount a Generic FS and write just "blbost" into the Working Directory
textfield. Then try to execute some file via internal execution. Or
try to mount another Generic VCS filesystem.

Created attachment 9836 [details]
Context patch for the last change in VcsAttributes.

Created attachment 9837 [details]
The binary patch for the last change in VcsAttributes. Put into <NB-install>/modules/autoload/patches/org-netbeans-modules-vcscore/ folder.

IMHO: Martin, you've probably omited /patches/ in the path location
for your path:
2003-04-10 02:00 PDT: Patch32698_vcscore.jar

tha path had to be the same as for your another patch:
2003-04-10 03:45 PDT: Patch32698_2_vcscore.jar

which is:
<NB-install>/modules/autoload/patches/org-netbeans-modules-vcscore/
folder.
---------------------------------------------------------------------


I tested intensively all 3 last provided patches from you on win XP
using the same build as yesturday (with removed the previous patch)
only on G-CVS FS (CVS profile only)

I tested with basic cvs commands which works without problem...
But I found that file's statuses aren't actualizied according to their
real statuses :-(((

Maybe it somehow relates to the fact that I try to mount my working as
only:
 F:
not 
 F:\

so try to fix that user doesn't need choose drive by mouse, but s/he
could type it as simply as it is possible...

I'm sorry but I rather reopening it, but IMHO it's much better then it
was before;-)

and now to description of my situation:
=======================================
I create a text file NOT IN THE ROOT OF F:
but 3 levels deeper. All above was already exist (it was added&commited).
After ADD, File stay [local] in source editor and in the explorer, but
tooltip on hte file said [Locally Added]
and also IconBadging works fine;-) 
Then I commited this file. Still the same situation....
except tooltip and IB...

Previously I played on onther drive only with update, checkout,
refreses, merging... and in that case I didn't recognize any problems
with file statuses :-/

I just believe it is related to how the working drive is 
specified: if it is 'F:' or 'F:\'
But it is sound strange when I thinking more about it :-\

I'm working on further fixes:
- We will not allow to mount "E:" - only "E:\" can be mounted.
- file status changes are badly fired. Nobody has ever thought, that
root dir can end with File.separator, so every fired name has cut the
first letter.

Fixed (again) in NB 4.0:

/cvs/vcscore/src/org/netbeans/modules/vcscore/VcsFileSystem.java,v 
<--  VcsFileSystem.java
new revision: 1.222; previous revision: 1.221

I'll attach new contextual and binary patches...

Created attachment 9871 [details]
The full context diff of all the changes, that fix this bug.

Created attachment 9872 [details]
The new binary patch for vcscore module. Put this into <NB-install>\modules\autoload\patches\org-netbeans-modules-vcscore\ folder instead of the old patches. Use together with the Patch32698_cvs-profile.jar.

Well I tested on todays NB3.5Beta
  Product Version       = NetBeans IDE 3.5 Beta (Build 200304102350)
  IDE Versioning        = IDE/1 spec=3.42.1 impl=200304102350
  Operating System      = Windows XP version 5.1 running on x86
  Java; VM; Vendor      = 1.4.2-beta; Java HotSpot(TM) Client VM
1.4.2-beta-b19; Sun Microsystems Inc.
  Java Home             = C:\Program Files\Java\j2sdk1.4.2\jre
  System Locale; Encod. = en_GB; Cp1252
  Home Dir; Current Dir = C:\Documents and Settings\dm103276;
C:\space\NetBeans IDE 3.5beta
  IDE Install; User Dir = C:\space\NetBeans IDE 3.5beta; C:\Documents
and Settings\dm103276\.netbeans\3.5beta
============================================================
and I think, it's getting better and better ;-)

Yes, IHMO, it is fixed and never could happen to user any damage on
his usr_dir, no E. is thrown, file statuses are working correctly now,
etc.

So, QA say: go ahead and fix it, please!!! :-)

-------------------------------------------------------------
But anyway, with this fix I discovered previously hidden P1 bug which
I consider as a new showstopper for NB3.5/Nevada:-(((
I'm going to enter it against vcsgeneric 'cause it is relatid to
vcs-profiles and it is about that basic cvs commands, such co, up and
prob ably import doesn't work

(I''ll let you know the ussue no. here)

So, the no. is: issue #32828

Code reviewed without objections.

approved for 3.5 

Thanks for the review, verification and approval.
The fix is merged into release35 branch:

Checking in cache/CacheDir.java;
/shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/cache/CacheDir.java,v 
<--  CacheDir.java
new revision: 1.32.2.1; previous revision: 1.32
Checking in caching/VcsCache.java;
/shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCache.java,v 
<--  VcsCache.java
new revision: 1.56.2.2; previous revision: 1.56.2.1
Checking in VcsFileSystem.java;
/shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/VcsFileSystem.java,v 
<--  VcsFileSystem.java
new revision: 1.207.2.11; previous revision: 1.207.2.10
Checking in VcsAttributes.java;
/shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/VcsAttributes.java,v 
<--  VcsAttributes.java
new revision: 1.22.36.6; previous revision: 1.22.36.5

One more merge to release35 ;-)

Checking in
src/org/netbeans/modules/vcs/profiles/cvsprofiles/list/CvsListRecursiveCommand.java;
/shared/data/helm/cvs/repository/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/list/CvsListRecursiveCommand.java,v 
<--  CvsListRecursiveCommand.java
new revision: 1.8.2.1; previous revision: 1.8