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: | deserialization of cached filesystem info not working correctly | ||
---|---|---|---|
Product: | obsolete | Reporter: | pswisnov <pswisnov> |
Component: | vcscore | Assignee: | Martin Entlicher <mentlicher> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | ||
Priority: | P1 | ||
Version: | -S1S- | ||
Hardware: | Sun | ||
OS: | Solaris | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
The context diff with respect to release35 branch.
The binary patch. Copy to <NB-install>/modules/autoload/patches/org-netbeans-modules-vcscore/ folder. |
Description
pswisnov
2003-03-21 18:35:02 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... 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. 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.
Hm, I will take a look at it. However it works for me here. 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. 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. 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. Created attachment 9644 [details]
The context diff with respect to release35 branch.
Created attachment 9645 [details]
The binary patch. Copy to <NB-install>/modules/autoload/patches/org-netbeans-modules-vcscore/ folder.
Jiri, can you please verify the fix with the attached patch under ClearCase? Thanks. 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. Reviewed. The fix is really trivial. approved by release coordinator for 3.5 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 Perfect, verified in Sun ONE Studio 5.0 Standard Edition build #030521. |