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.
[NBdev-200108240715] jdk1.3.0_04,rh70, also appears on M$Win ======================================= Descriptinon: ------------- There's must be something still wrong with FileSystems. When you mounting new FS usualy should appears as the last node in the Explorer. But SOMETIMES it happen that currently mounted FS isn't added as the last one in the Explorer but somewhere in the midle of already mouted FSs. It happens me only (or I only noticed it) with JAvaCVS FSs;-( so I'm firing this bug for JAvaCVS component but if you thing that it belongs to openide or vcscore, feel free and reasigne the component. Thanks. Reproduction: ------------- isn't so easy or 100% pure:-( But after a while mounted max.10 FSs) you must reproduce it. Here it is: Take a new or this NB-dev build. run it with "clear user settings" (no nbdev dir) or run it with '-userdir /tmp/mysettings' switch. 1.After start of pure 'clear" NBdev build you will see already mounted 1 FS in the Explorer. 2.Mount JAvaCVS FS as folows in description here: MainMenu->Versioning->Mount VCS->CVS 3.It will be positioned as the first FS in your Explorer. 4.Repeated step 2. 5.The result will be that 2 JavaCVS are close to each other and "lokal"FS=sampledir will be the last one. 5. Mount eg. Generic CVS, zip, dir FS (in the way you like) all that types of FS will be always added as the last node in the Explorer. 6.Sometimes try to mount JAvaCVS again(doesn't matter in which way you will mounted). Probably will be added at the end in the Explorer, 7. But mount eg.Generic CVS and imediately JavaCVS again. 8.Now JavaCVS will be mounted above Generic CVS (it will be the last but one).Mount other JAvaCVS FS. 9.no one of them will be the last. I hope that it doesn't sound complicated. Also I give priority P3, because it doesn't happen always and if it does it isn't harmful.
I don't have any influence over the filesystems sorting. (Or at least I think so, please corrent me if I'm wrong) So I'm moving this to openide..
Sorry, but cannot reproduce in dev#20010907. Can you reproduce this in latest dev builds? I know that there are still some weaknes in automount but this one really works form me.
Jan, the reproduction isn't so easy but it is possible at least on Friday dev-build #200109070100 for me on linux. In todays build #200109100100 I wasn't succesful with reproduction:-( but anyway I think this bug still persists, so reopening it.
Ok, passing to Yarda. Seems like neverending automount stories. BTW why reopenning when you cannot reproduce it now in the latest build? ;-)
I reopen it because I don't have any kind of sureness that there has been done any attempt to fix it. You just only said that you cannot reproduce it.... It's hard to reproduce and I wasn't sucessfull on the last build but on previous one I was and on the one before previous one I wasn't so it is non deterministic and saying if it didn't occure in current build thet this is invalid or worksforme isn't right. Because You didn't have "lucky" to reproduce, not thtat there has been done a fix. Once Yarda, or any other developer says to me: I tried to fix it with this ....code and then I won't be able to reproduce it then I could say and believe that it won't appeare because it was fixed... Do you understand me?
Ok, but how we can fix it, when nobody see the behaviour and you cannot reproduce it reliable. This can be affected by settings stuff as weel as by the automount. Some test case will be very helpfull. The reproduction steps aren't very clear and contains too much freedom to be reliable. Do you understand me? ;-)
Well, It couldn't be caused by my settings because I said to use "clear build without previously used userdir. and you're right that reproduction isn't exact procedure:-( I must say that I took older build and reproduction is sometimes possible, and in the a few last ones I wasn't sucessful... so,I simply don't understand how that behaviour "somehow" disappeared if noone made any attempt to fix it? Sounds to me like enigmatic paranormal phenomenon:-/ or somethink like this:-) OK, this isn't so serrious bug, so wasting time over it isn't much sufficient. So do what you think is the best;-)
When I said settings stuff I didn't mean your settings I meant the code in the openide that highly affect this. And this part of openide is changing rapidly, so this can be the root of it. When we go deeply into the code we can say that this can be afected by recent chages in filesystems - there was implemented atomic actions with ID and this change was requested by J.Pokorsky for settings. Leave the final resolution on Yarda when he will be back.
OK;-) I agree with you. Thanks
I have improved the code to always add the newly created object to the end. MountNode rev. 1.7 But it is necessary that CVS wizard iterator will return the DataObject that it created. Does it?
Jarda, could you,pls, specify in which build the improved code should appeare? I'm asking you because I was able to reproduce it on Friday "Q-Build " #20010921xxx so,I rather reopen it again:-) and If the fix has been done after this build (you wrote a note here 25/09), pls, mark this bug as fixed:-)
Is following ok? logout~/work/core/src/org/netbeans/core$ cd ui/ logout~/work/core/src/org/netbeans/core/ui$ cvs log MountNode.java RCS file: /cvs/core/src/org/netbeans/core/ui/MountNode.java,v Working file: MountNode.java head: 1.7 branch: locks: strict access list: symbolic names: BLD200109240100: 1.6 BLD200109220100: 1.6 BLD200109210100: 1.6 BLD200109200100: 1.6 BLD200109190100: 1.6 BLD200109180940: 1.6 BLD200109140100: 1.6 BLD200109130100: 1.6 BLD200109120100: 1.6 BLD200109110100: 1.6 BLD200109100100: 1.6 BLD200109070100: 1.6 settings_categories_after_merge: 1.6 settings_categories_before_merge: 1.6 BLD200109050100: 1.6 BLD200109040100: 1.6 BLD200109030100: 1.6 BLD200108310100: 1.6 BLD200108300704: 1.6 BLD200108300100: 1.6 BLD200108290100: 1.6 BLD200108280100: 1.6 BLD200108270715: 1.6 BLD200108270100: 1.6 BLD200108240715: 1.6 BLD200108240100: 1.6 BLD200108230100: 1.6 workspace_layers_august01_after_merge: 1.6 workspace_layers_august1_before_merge: 1.6 BLD200108220100: 1.6 BLD200108210100: 1.5 BLD200108200100: 1.5 BLD200108170100: 1.5 mime-resolvers: 1.5.0.2 ROOT-mime-resolvers: 1.5 BLD200108160100: 1.5 BLD200108100740_qbe1: 1.5 BLD200108150100: 1.5 workspace_layers_august01: 1.4.0.6 workspace_layers_august01_before_merge: 1.6 term_aug2001: 1.4.0.4 term_aug2001_before: 1.4 BLD200108140100: 1.4 qbe1: 1.4.0.2 BLD200108130100: 1.4 BLD200108100740: 1.4 BLD200108100100: 1.4 BLD200108090100: 1.4 BLD200108080100: 1.3 BLD200108060100: 1.3 BLD200108030100: 1.3 BLD200108020100: 1.3 projects_40: 1.3.0.2 projects_40_root: 1.3 BLD200108010100: 1.3 BLD200107310100: 1.3 BLD200107300100: 1.3 workspace_layers_june01_after_merge: 1.3 BLD200107270100: 1.3 workspace_layers_june01_before_merge: 1.3 BLD200107260100: 1.3 BLD200107250100: 1.1 keyword substitution: kv total revisions: 8; selected revisions: 8 description: ---------------------------- revision 1.7 date: 2001/09/25 13:07:36; author: jtulach; state: Exp; lines: +4 -0 Should not guarantee that the newly added object will be at the end ---------------------------- revision 1.6 date: 2001/08/21 14:41:34; author: jtulach; state: Exp; lines: +16 -0 Rename dissabled on FileSystem Settings node. ---------------------------- revision 1.5 date: 2001/08/14 14:46:14; author: jtulach; state: Exp; lines: +18 -16 Fix of #14331. FileSystem order is kept after restart. ---------------------------- revision 1.4 date: 2001/08/08 08:58:09; author: jtulach; state: Exp; lines: +28 -0 branches: 1.4.2; If filesystems are added before AutomountSupport is initialized then storeTask is invoked. Order of stored filesystems is kept. build.xml is modified to delete system/Mount directory. usersguide layer declares instanceClass in correct way. ---------------------------- revision 1.3 date: 2001/07/25 18:02:26; author: jglick; state: Exp; lines: +2 -3 No semantic change; compilability with Jikes. ---------------------------- revision 1.2 date: 2001/07/25 10:33:53; author: jtulach; state: Exp; lines: +23 -4 Mount wizard for jar and directory shows location panel ---------------------------- revision 1.1 date: 2001/07/24 09:10:23; author: jtulach; state: Exp; Mount wizard based on template wizard ---------------------------- revision 1.4.2.1 date: 2001/08/13 16:39:09; author: jtulach; state: Exp; lines: +18 -16 Correct mounting of filesystems ============================================================================= logout~/work/core/src/org/netbeans/core/ui$
ufff....the fix had to appeare in build #20010925 as I understand... But as I said I was able to reproduce on [NBdev-200110010100] too and TWICE in a row and I'm sending you my ide.logs zipped in a archive. So focus on 2 or 3 last IDE's starts. My STEPS TO REPRODUCE are still the same: (Steps in Brackets "()" aren't necesseary IMHO, but I done them) ================================================================ 1. (Have only mounted default FS which is usualy: ~/nbdev/sampledir) 2. Now I'm going to the File menu and select Mount Filesystems 3. In the Mounting wizard I select a LOCAL type and mount "MYDIR". (Expand it and open a file in editor) 4. Go to the Versioning menu and choose Generic VCS select CVS profile and all necessery properties like Working dir, relative mount point,.... 5. Imediately go again into Versioning menu and select JavaCVS FS type Go through the wizard and before you press FINISH button make visible your Explorer Window and watch it where the FS will be added. 6. Press FINISH button. The JAvaCVS is really added at the and BUT JUST ONLY FOR A SECOND!!! Then it's moved before Gen-CVS FS. ---------------------------------------------------------------------- This reproduction is very easy for me on #200110010100 build I hope this "frame" of my workflow isn't related to my previous actions in IDE like UN/INSTALLING VCS modules issue #16073 or "losting FS after restart" issue #15513 and many restarts of IDE.
Created attachment 2786 [details] 2 ide logs which should contain enought "history" of action with reordering FSs
Created attachment 2787 [details] IMHO unuselles odd and too old history, but maybe it could help if the first attachment isn't enough
Changes to AutomountSupport done on Oct2 and in FolderInstance on Oct3. I believe this is fixed, but remembering the past experience, I will change this to remain only.
Reopening to duplicate.
*** This issue has been marked as a duplicate of 16441 ***
OK
Resolved for 3.4.x or earlier, no new info since then -> closing.