Community
Participate
Working Groups
I'm running 3.1 M6 on XP. I tried to import an existing project from a network drive which is mapped to a share on a Windows 2003 server. I have full rights to this share. The project is a simple project, originally created in 3.0.x just so my team could sync some text files to our CVS server easily. I tried Import | Existing Project into Workspace...navigated to the network U: drive, chose my project, clicked Finish. The new project shows in the Navigator view of the Resource perspective, but when I expand it, all I see is the ".project" file, even though there are clearly other files on the U: drive. I made sure there were no Filters in effect in the Navigator view as well. I tried the same thing again--but using the full UNC path to the share instead of the simple drive letter--and get the same results...only .project shows up. I copied the contents of the network drive locally and tried importing the project, and it works perfectly fine...all files appear in the Navigator view. I even tried Import | File system, to "import" the existing files on the share "back into" the shared project and am correctly prevented from doing this. The Import dialog browses the network share perfectly fine but displays an error stating, "Source is in the hierarchy of the destination." when I select any files or folders on the share, as it should. As I alluded to earlier, the project is "connected" to a CVS repository. When I import the project from the network drive, and choose Team | Share Project, the dialog that appears acts as if the project isn't already part of CVS...since it can't "see" any CVS resources in the project. Again, if I try Team | Share Project on the local copy of the project, I get a dialog that says something like, "It appears this project is already part of CVS...would you like to use the existing repository settings?"...which is the behavior I'd expect. I've attached a screen shot of the "empty" project and the actual share's content as viewed in Windows. It just appears that files/folders on a network share aren't seen by Eclipse as real "Resources".
Created attachment 20138 [details] Screen shot of "empty" project imported from a network drive This image shows many files on the U: drive, even though the imported project only shows a single .project file.
It appears to be a general problem of discovering files at the root level. If I create a project inside a:\ (floppy drive), I see the same problem. To confirm, could you try mapping "U:" one level higher in your network directory tree, so that the project doesn't sit at the drive root level?
*** Bug 92523 has been marked as a duplicate of this bug. ***
Our native method to obtain the "stat" (file timestamp and other information), does not work at the root level. I looked back to Eclipse 3.0, and I see the native stat does not work at the root level either. However, importing a project or linked folder at the root level does work in 3.0. The reason it stopped working in 3.1 is that we added this optimization in UnifiedTree#addChildren 3.0 implementation: Object[] list = getLocalList(node, parentLocalLocation); 3.1 implementation: Object[] list = node.existsInFileSystem() ? getLocalList(node, parentLocalLocation) : NO_CHILDREN; I.e., the 3.1 implementation avoids going to the file system to get the children if the resource does not exist. Since the stat failed, "existsInFileSystem()" returns false, and it skips fetching the children.
Our core native uses the win32 call, FindFirstFileW. The doc for this method says that it does not work for the root directory. To search in the root you need to add the '*' wild card, such as "c:\*" for the root of the c: drive. I tried a quick hack, and this seemed to work. The timestamp was strange, but the stat call did not return failure. Interestingly, calling java.io.File#lastModified on the root directory returns a negative number, so the class library doesn't seem to handle this case very well either. In any case, the timestamp for the root isn't too important because it cannot be modified or deleted anyway. If I "fake out" the root directory case on windows, everything seems to work just fine. I.e., I added this test to CoreFileSystemLibrary#getStat: if (isWindows && fileName.length() == 3 && fileName.endsWith(":\\")) return STAT_VALID | STAT_FOLDER; It might be better to hide this platform-specific issue directly in the native code rather than exposing it at the Java layer, but this solution seems to work.
(In reply to comment #2) > It appears to be a general problem of discovering files at the root level. If I > create a project inside a:\ (floppy drive), I see the same problem. > > To confirm, could you try mapping "U:" one level higher in your network > directory tree, so that the project doesn't sit at the drive root level? "Root" problem confirmed. I mapped the drive to a higher level and the project was imported correctly. I also tried copying the project to the root of a local drive and the original problem persisted, so it doesn't look like it matters whether the drive is local or mapped...the problem does indeed seem to lie in reading the root of a drive. (Incidentally, I went back and tried using the full UNC path to the project location and the project imported fine this time--I must have goofed up on this particular case in my original post when I stated it did not work. Anyway, I'd say the problem is "in" the root.)
Updating title to more accurately reflect the issue. The problem is with any resource (project or linked folder) whose location is the root of a Windows file system.
Fix released. I have fixed the native code on Windows to handle the root directory case properly.
*** Bug 100103 has been marked as a duplicate of this bug. ***
I just ran into this with Eclipse 3.3M5 (I20070209-1006) on Windows XP SP1, with the Sun 1.5.0_11 JVM. BTW, I found this bug via bug 100103 by searching for summary: "linked drive". In Resource Navigator, select any project New > Folder, Advanced, name="i", link to folder in filesystem: "I:\", OK --> The folder is displayed with a little exclamation mark, Properties say: Type=Linked Folder, Location=I:\ - (does not exist) When I link to a subfolder below I:\ it works OK. About dialog says that org.eclipse.core.filesystem.x86.win32 is 1.0.0.v20060603
*** Bug 177134 has been marked as a duplicate of this bug. ***
*** Bug 183529 has been marked as a duplicate of this bug. ***
This regression was caused by the fix for bug 30995. Adding the \\?\ notation to paths broke the test in the native code to identify a root path. Consider for RC1.
Created attachment 65696 [details] Fix
Created attachment 65697 [details] Regression test
Native fix and regression test released.
