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 16513 - Filesystems: Filesystems are ordered after moumting new one
Summary: Filesystems: Filesystems are ordered after moumting new one
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: All All
: P1 blocker (vote)
Assignee: Vitezslav Stejskal
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-10-12 13:25 UTC by Marian Mirilovic
Modified: 2008-12-22 16:39 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
ide.log (123.40 KB, text/plain)
2001-10-12 13:41 UTC, Jan Zajicek 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Marian Mirilovic 2001-10-12 13:25:36 UTC 
[nb_dev](20011012),[jdk1.3.1](rc1)

Steps to reproduce:
- run IDE ( now is mounted sampledir )
- mount some jar ( xx.jar )
- mount some Local directory ( some/directory )
-> now Filesystems ordered and order is :
	1. sampledir
	2. some/directory
	3. xx.jar

If you had expanded some filesystem, that one is collapsed.
Comment 1 Jan Zajicek 2001-10-12 13:38:55 UTC 
Adding log for following scenario:

1. start 3.3
2. mount javacvs
3. mount jar
4. mount localdirectory

Final order:
1.localdirectory
2.jar
3.cvs
Comment 2 Jan Zajicek 2001-10-12 13:41:05 UTC 
Created attachment 2988 [details]
ide.log
Comment 3 Jaroslav Tulach 2001-10-12 14:41:49 UTC 
Not reproducible without projects module.
Comment 4 Jan Chalupa 2001-10-12 15:27:16 UTC 
Affects classpath -> P1.
Comment 5 Vitezslav Stejskal 2001-10-16 19:15:12 UTC 
This problem was discovered when I have added FilterFileSystem 
implementation into the core and used it in SessionManager as a 
project layer. The FFS delegates to another filesystem and uses some 
FileObject from that filesystem as a root point. All FOs accessible on 
the FFS are shifted in comparision to original FOs on the delegate 
filesystem.

Current implementation of MultiFileObject.getAttribute doesn't expect 
this and uses precomputed path when asking delegates. Precomputed 
path isn't valid for delegates from the shiftig file system and thus 
no attribute is found. I have change it to ask delegates without 
passing precomputed path, thus each delegate computes its own path 
again now. It fixes functionality but causes performance regression. I 
have filed PERFORMANCE issue #16618 against the filesystems in order 
to measure this regression and correct it.
Comment 6 Marian Mirilovic 2001-10-17 09:25:27 UTC 
verified in [nb_dev](20011017)
Comment 7 Quality Engineering 2003-07-01 16:50:23 UTC 
Resolved for 3.4.x or earlier, no new info since then -> closing.