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 32198 - deserialization of cached filesystem info not working correctly
Summary: deserialization of cached filesystem info not working correctly
Status: VERIFIED FIXED
Alias: None
Product: obsolete
Classification: Unclassified
Component: vcscore (show other bugs)
Version: -S1S-
Hardware: Sun Solaris
: P1 blocker (vote)
Assignee: Martin Entlicher
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-03-21 18:35 UTC by pswisnov
Modified: 2003-07-15 10:46 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
The context diff with respect to release35 branch. (1.11 KB, patch)
2003-04-02 08:53 UTC, Martin Entlicher
Details | Diff
The binary patch. Copy to <NB-install>/modules/autoload/patches/org-netbeans-modules-vcscore/ folder. (5.87 KB, application/octet-stream)
2003-04-02 08:58 UTC, Martin Entlicher
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pswisnov 2003-03-21 18:35:02 UTC
I'm seeing wierd stuff when I mount a clearcase
volume and restart the IDE. Objects in the
clearcase volume have strange annotations. The
list command does not get run, so it must be
getting info from a cache. Here is some mail from
Martin:

This is strange. I'll ask our testers next week if
they have this problem as
well.
The brackets are coming from the annotation
pattern (filesystem property
"Annotation Pattern").
The '0' in lost+found [/main/0; 0] comes from the
'revision' field.
The '0' in t1 [main/bugfix/4] (0) comes either
from locker or sticky.

Since the LIST command does not provide these
fields, it had to occur from
somewhere else. It can be some problem of status
read/write to the disk cache
(The file status information is written to the
disk cache so that the Refresh
does not have to be called again and again. This
disk cache is located at <user
dir>/system/vcs/cache/<cache number>/*. The cache
number is in Expert
properties of the filesystem.)

If this problem occurs regularly, please file an
issue for vcscore module and
we try to reproduce it here and provide a fix.
Comment 1 Martin Entlicher 2003-03-24 15:58:45 UTC
This seems to be caused by an inconsistent read/write of the disk
cache information.

I'll work on a fix in the main trunk...
Comment 2 pswisnov 2003-03-24 23:02:32 UTC
One thought...in a system like clearcase with dynamic views, it seems
odd to be caching anything in the first place, since stuff can be
updated without the user having executed any update command.
Comment 3 Martin Entlicher 2003-03-26 16:58:07 UTC
Reverting Target Milestone back to TBD. This is not yet evaluated,
it's not clear where exactly is the problem.

> One thought...in a system like clearcase with dynamic views, it
> seems odd to be caching anything in the first place, since stuff can
> be updated without the user having executed any update command.

vcsgeneric module by default creates the file status cache for all
profiles. However VcsFileSystem in vcscore can be functional without
the status caching (although this was not tested recently). Perhaps a
property could be added so that the profiles can decide whether to use
the cache or not. This can be an enhancement for NB 4.0.
Comment 4 Jiri Kovalsky 2003-04-01 09:12:00 UTC
Hm, I will take a look at it. However it works for me here.
Comment 5 Jiri Kovalsky 2003-04-01 10:00:12 UTC
Hm, ignore my previous comment since I have just reproduced it. So, I
confirm that before restart the node had [/main/3] status and after
restart it had [/main/3; 0].
Anyway, is this really P2 ? To be honest I would see it as P4.
Comment 6 Martin Entlicher 2003-04-01 15:18:34 UTC
Well, in general this is a data corruption. The bug is probably
reproducible only on UNIX system, because one of the item in the cache
(the status) contains slash (/), which is also used as a delimeter of
the cache items.
This case is already handled in I/O operations, but it looks like
there's a mistake. I'm going to test it and I'll hopefully find where
is the problem.
Comment 7 Martin Entlicher 2003-04-01 21:44:10 UTC
The bug is fixed in the main trunk. There was a small mistake in the
parsing of elements from the cached line:

/cvs/vcscore/src/org/netbeans/modules/vcscore/caching/RefreshCommandSupport.java,v
 <--  RefreshCommandSupport.java
new revision: 1.29; previous revision: 1.28

We should probably merge this into release35, the fix is trivial and
safe. The bug causes strange looking annotations in ClearCase and can
have also bad effect on other 3rd party profiles.
So I'm upgrading this to P1.
Comment 8 Martin Entlicher 2003-04-02 08:53:36 UTC
Created attachment 9644 [details]
The context diff with respect to release35 branch.
Comment 9 Martin Entlicher 2003-04-02 08:58:52 UTC
Created attachment 9645 [details]
The binary patch. Copy to <NB-install>/modules/autoload/patches/org-netbeans-modules-vcscore/ folder.
Comment 10 Martin Entlicher 2003-04-02 09:00:18 UTC
Jiri, can you please verify the fix with the attached patch under
ClearCase? Thanks.
Comment 11 Jiri Kovalsky 2003-04-02 09:27:10 UTC
Wonderful, it's working fine with the patch. The status remains same
after IDE restarts. Verified in Sun ONE Studio 5.0 #030325 with
Patch32198.jar.
Comment 12 Tomas Pavek 2003-04-02 11:44:07 UTC
Reviewed. The fix is really trivial.
Comment 13 _ ttran 2003-04-02 12:58:37 UTC
approved by release coordinator for 3.5
Comment 14 Martin Entlicher 2003-04-02 14:36:14 UTC
Thanks for the review, verification and approval.
It's integrated in release35 branch:

/cvs/vcscore/src/org/netbeans/modules/vcscore/caching/RefreshCommandSupport.java,v 
<--  RefreshCommandSupport.java
new revision: 1.28.36.1; previous revision: 1.28
Comment 15 Jiri Kovalsky 2003-07-15 10:46:23 UTC
Perfect, verified in Sun ONE Studio 5.0 Standard Edition build #030521.