Community
Participate
Working Groups
Build ID: HEAD Steps To Reproduce: I just tried ctrl+dragging a folder from one project to another choosing: "Recreate files and directories hierarchy using groups and linked resources". This worked fine in the case of copying normal resources. However when I did the same with a folder which contained linked resources, I got an error: Problems occurred while copying resources: Path variable name cannot contain character: -. The file system is read only link1/CVS The file system does not support deletion: link1/foo.c The file system does not support deletion: link1/bar.c ...
I tried to reproduce this issue with the latest changes from HEAD, and it works fine. Could you update the e4 resource plugins to today's version and let me know if you are still able to reproduce it? Thanks!
adding my other email
The resulting tree seems valid i.e it exists. But the contents aren't solely groups and links. Folder level linked resources remain folder level linked res. rather than being converted to groups, and for each folder-level linked resource I end up with an error in the error log: java.net.URISyntaxException: Relative path in absolute URI: null:stand_alone_src at java.net.URI.checkPath(URI.java:1787) at java.net.URI.<init>(URI.java:662) at java.net.URI.<init>(URI.java:764) at org.eclipse.core.internal.filesystem.NullFileStore.toURI(NullFileStore.java:101) at org.eclipse.core.internal.localstore.FileStoreRoot.computeURI(FileStoreRoot.java:89) at org.eclipse.core.internal.localstore.FileSystemResourceManager.locationURIFor(FileSystemResourceManager.java:630) at org.eclipse.core.internal.resources.Resource.getLocationURI(Resource.java:1230) at org.eclipse.core.internal.resources.Resource.checkCopyRequirements(Resource.java:273) at org.eclipse.core.internal.resources.Resource.assertCopyRequirements(Resource.java:143) at org.eclipse.core.internal.resources.Resource.copy(Resource.java:548) at org.eclipse.ui.ide.undo.WorkspaceUndoUtil.copy(WorkspaceUndoUtil.java:494) at org.eclipse.ui.ide.undo.WorkspaceUndoUtil.copy(WorkspaceUndoUtil.java:477) at org.eclipse.ui.ide.undo.CopyResourcesOperation.copy(CopyResourcesOperation.java:154) at org.eclipse.ui.ide.undo.CopyResourcesOperation.doExecute(CopyResourcesOperation.java:122) at org.eclipse.ui.ide.undo.AbstractWorkspaceOperation$1.run(AbstractWorkspaceOperation.java:206) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1952) at org.eclipse.ui.ide.undo.AbstractWorkspaceOperation.execute(AbstractWorkspaceOperation.java:204) at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:511) at org.eclipse.ui.actions.CopyFilesAndFoldersOperation.performCopy(CopyFilesAndFoldersOperation.java:1224) at org.eclipse.ui.actions.CopyFilesAndFoldersOperation.copyResources(CopyFilesAndFoldersOperation.java:1739) at org.eclipse.ui.actions.CopyFilesAndFoldersOperation.access$1(CopyFilesAndFoldersOperation.java:1693) at org.eclipse.ui.actions.CopyFilesAndFoldersOperation$2.run(CopyFilesAndFoldersOperation.java:613) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
This seems to be caused by the recent changes in the implementation of the group feature (see bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=264878) I'm able to reproduce the error log when I copy a linked resource folder that has linked resource children in a new project. The stack trace originates from EFS.getStore(rootURI).getChild(childPath).toURI(); Where "rootURI" is in my case "group:/group" and childPath is "foo.txt". John, do you hav any input on that issue?
I'll look into it. Is there any trick to reproducing it? Serge you initially couldn't reproduce it, is that because you were using an older build?
(In reply to comment #5) > I'll look into it. Is there any trick to reproducing it? Serge you initially > couldn't reproduce it, is that because you were using an older build? > I'm able to reproduce the error log by using the following setup: Project1 - folder - - linked resource folder - - linked file folder Project2 And drag and dropping (with the control key pressed) "folder" onto Project2, and selecting "Recreate files and directories hierarchy using groups and linked resources" in the dialog. The only thing I'm able to reproduce is the error log, the groups and linked resources get created properly for me. I'd need more reproducibility information from James to be able to reproduce a problem in terms of not creating the proper copied resources.
(In reply to comment #5) > I'll look into it. Is there any trick to reproducing it? Serge you initially > couldn't reproduce it, is that because you were using an older build? If you can't reproduce easily, do say and I'll provide more detailed steps. It happens readily here. Also moving groups doesn't appear to work at all at the moment (using the bits from yesterday). Just dragging the group (any group) gives: java.lang.NullPointerException at org.eclipse.core.internal.resources.LocationValidator.validateLinkLocation(LocationValidator.java:76) at org.eclipse.core.internal.resources.Workspace.validateLinkLocation(Workspace.java:2192) at org.eclipse.ui.actions.CopyFilesAndFoldersOperation.validateLinkedResource(CopyFilesAndFoldersOperation.java:1597) at org.eclipse.ui.actions.CopyFilesAndFoldersOperation.validateDestination(CopyFilesAndFoldersOperation.java:1452) at org.eclipse.ui.actions.MoveFilesAndFoldersOperation.validateDestination(MoveFilesAndFoldersOperation.java:242) at org.eclipse.ui.navigator.resources.ResourceDropAdapterAssistant.validateDrop(ResourceDropAdapterAssistant.java:141) at org.eclipse.ui.navigator.CommonDropAdapter.validateDrop(CommonDropAdapter.java:214) at org.eclipse.jface.viewers.ViewerDropAdapter.doDropValidation(ViewerDropAdapter.java:181) at org.eclipse.jface.viewers.ViewerDropAdapter.dragOver(ViewerDropAdapter.java:227) at org.eclipse.swt.dnd.DNDListener.handleEvent(DNDListener.java:80)
(In reply to comment #6) > (In reply to comment #5) > I'm able to reproduce the error log by using the following setup: > > Project1 > - folder > - - linked resource folder > - - linked file folder > Project2 > > And drag and dropping (with the control key pressed) "folder" onto Project2, > and selecting "Recreate files and directories hierarchy using groups and linked > resources" in the dialog. > > The only thing I'm able to reproduce is the error log, the groups and linked > resources get created properly for me. It could be an issue of expectation. The destination tree looks good, but I was expecting all the containers to have been converted to groups (which may be wrong). In my case: Project1 - folder - - linked resource folder <some_file>.c In the destination I was expecting linked resource folder to to have turned from a link to a group, and <some_file>.c to now be a link. Instead 'linked resource folder' is still a linked resource. The rationale is that if the user is using this action for creating completely virtual trees, they may want to delete other children of the new 'linked resource folder'. In the above example, deleting <some file>.c in the Project2 deletes the underlying resource.
(In reply to comment #7) > (In reply to comment #5) > > I'll look into it. Is there any trick to reproducing it? Serge you initially > > couldn't reproduce it, is that because you were using an older build? > > If you can't reproduce easily, do say and I'll provide more detailed steps. It > happens readily here. > > Also moving groups doesn't appear to work at all at the moment (using the bits > from yesterday). > > Just dragging the group (any group) gives: > > java.lang.NullPointerException > at This bug is now fixed on the e4 resource CVS HEAD.
(In reply to comment #9) > (In reply to comment #7) > > (In reply to comment #5) > > > I'll look into it. Is there any trick to reproducing it? Serge you initially > > > couldn't reproduce it, is that because you were using an older build? > > > > If you can't reproduce easily, do say and I'll provide more detailed steps. It > > happens readily here. > > > > Also moving groups doesn't appear to work at all at the moment (using the bits > > from yesterday). > > > > Just dragging the group (any group) gives: > > > > java.lang.NullPointerException > > at > > This bug is now fixed on the e4 resource CVS HEAD. > I mean, the NullPointerException mentioned above is now fixed, not the general issue described in this bug report.
(In reply to comment #8) > > It could be an issue of expectation. The destination tree looks good, but I was > expecting all the containers to have been converted to groups (which may be > wrong). In my case: > Project1 > - folder > - - linked resource folder > <some_file>.c > > In the destination I was expecting linked resource folder to to have turned > from a link to a group, and <some_file>.c to now be a link. Instead 'linked > resource folder' is still a linked resource. > > The rationale is that if the user is using this action for creating completely > virtual trees, they may want to delete other children of the new 'linked > resource folder'. In the above example, deleting <some file>.c in the Project2 > deletes the underlying resource. > I think you raise a good point. Currently, the rules when copying resources are: - If the resource is a linked resource or group, it gets copied without any change in type. - If the resource is not either linked or grouped, a dialog comes up, asking if file/folder linked resources should be created, or groups and file linked resources. - If the resource is not either linked or grouped, but the target is a group, then it gets automatically converted to a linked resource file/folder under the new group. There's not currently the possibility of transforming a linked resource folder into a hierarchy of groups and linked resource files, the way that normal folders can be converted into virtual hierarchies. Although it is possible to have the option available too, I feel it gets really complicated, especially when trying to communicate to the user the difference between copying a hierarchy of folders that has linked resources children to a hierarchy where linked resource folders and their non linked resource children get converted to groups and linked resource files. If we divide the use case in two modes, I think it helps sorting this out: 1) The use case where the user is not using a virtual project structure (no linked resources, no groups). 2) The use case where the user is using a virtual project structure (file/folder linked resources and groups). The dialog allows generally converting mode 1) into mode 2), but doesn't do more sophisticated things to reorganize a mode 2) structure, since the usage of folder linked resources already implies using the mode 2). If the user is determined to transform his folder linked resource into a hierarchy or groups and file linked, he can accomplish this by locating the linked resource target in Windows Explorer, and dragging that directory (now a normal folder) onto the destination. The confusion from the dialog comes from the fact that in the scenario described in this bug report, the user drags a normal directory, and that's why the dialog comes up. If he would drag and drop a linked resource or group instead, the dialog wouldn't come up, since it applies to normal resources.
(In reply to comment #9) > (In reply to comment #7) > > java.lang.NullPointerException > > at > > This bug is now fixed on the e4 resource CVS HEAD. Are you sure? I'm still seeing this...
(In reply to comment #12) > (In reply to comment #9) > > (In reply to comment #7) > > > java.lang.NullPointerException > > > at > > > > This bug is now fixed on the e4 resource CVS HEAD. > Are you sure? I'm still seeing this... Sorry, false alarm. I didn't pick up the changes in ui.ide.
(In reply to comment #11) > If we divide the use case in two modes, I think it helps sorting this out: > > 1) The use case where the user is not using a virtual project structure (no > linked resources, no groups). > > 2) The use case where the user is using a virtual project structure > (file/folder linked resources and groups). > > The dialog allows generally converting mode 1) into mode 2), but doesn't do > more sophisticated things to reorganize a mode 2) structure, since the usage of > folder linked resources already implies using the mode 2). Perhaps this is the crux of it. If the user is dragging something which contains virtual linked resources, then not touch the linked resources seems like a reasonable thing to do. > If the user is determined to transform his folder linked resource into a > hierarchy or groups and file linked, he can accomplish this by locating the > linked resource target in Windows Explorer, and dragging that directory (now a > normal folder) onto the destination. In the linux world users really aren't used to doing this... I don't think users expect drag and drop to work between whatever file navigator they've got and Eclipse. Furthermore this doesn't *quite* achieve the same thing. If some of the resources have filters applied, then the action of turning the existing tree to a pure virtual groups + links_to_files is different from Windows Explorer dnd of the full tree. > The confusion from the dialog comes from the fact that in the scenario > described in this bug report, the user drags a normal directory, and that's why > the dialog comes up. If he would drag and drop a linked resource or group > instead, the dialog wouldn't come up, since it applies to normal resources. Yes. And perhaps the current behaviour isn't wrong, it's just not what I was expecting having read the blurb. I guess I'm trying to work out when I'd use groups and when I'd use filters and when I'd mix them -- and then work out a way of explaining it all to the users. So much choice :)! It's all looking pretty good now, thanks!
Created attachment 127640 [details] Patch 1 Attached is a trivial patch which makes GroupFileStore getChild() create an NullFileStore using an absolute path. It makes sense that filesystems expect absolute paths when getting a filestore, however given that NullFileSystem is used has a dummy fs, perhaps it should be more tolerant about relative paths when creating the URI?
(In reply to comment #15) > Created an attachment (id=127640) [details] > Patch 1 > > Attached is a trivial patch which makes GroupFileStore getChild() create an > NullFileStore using an absolute path. It makes sense that filesystems expect > absolute paths when getting a filestore, however given that NullFileSystem is > used has a dummy fs, perhaps it should be more tolerant about relative paths > when creating the URI? > I'm not sure to understand what changes that patch causes, maybe John has some input there.
(In reply to comment #16) > I'm not sure to understand what changes that patch causes, maybe John has some > input there. NullFileSystem/Store is provided as a dummy fs implementation which isn't backed by anything. All this patch does is prevent the error of returning a null file store whose uri can't be fetched. AFAICS the group filestore is a dummy implementation which isn't intended to be used -- childNames and getChild(...) etc. are dummy implementations. Perhaps they should actually resolve the group's children? As far as I can tell the alias manager isn't resolving aliases under groups...
Created attachment 128015 [details] Test1 Test for the issue. Checks that the EFS filestore returned for the group doesn't return children with null URI. Perhaps the URI of the children should match their real URI rather than being a generated NullFileStore URI?
I still intend to look at this, just busy with 3.5 M6 at the moment. Serge, you can assign this to me if you like. It's related to the changes I made to the group implementation.
There you go :)
Related exceptions when doing CVS update in an outer project which overlaps with an inner project: java.net.URISyntaxException: Relative path in absolute URI: null:core_audio/bcom_algo_lib.h at java.net.URI.checkPath(URI.java:1787) at java.net.URI.<init>(URI.java:662) at java.net.URI.<init>(URI.java:764) at org.eclipse.core.internal.filesystem.NullFileStore.toURI(NullFileStore.java:101) at org.eclipse.core.internal.localstore.FileStoreRoot.computeURI(FileStoreRoot.java:89) at org.eclipse.core.internal.localstore.FileSystemResourceManager.locationURIFor(FileSystemResourceManager.java:630) at org.eclipse.core.internal.resources.Resource.getLocationURI(Resource.java:1234) at org.eclipse.cdt.core.index.IndexLocationFactory.getWorkspaceIFL(IndexLocationFactory.java:126) at org.eclipse.cdt.internal.ui.viewsupport.IndexedFilesLabelProvider.decorate(IndexedFilesLabelProvider.java:62) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:269) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:72) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:356) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:338) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:374) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:334) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
And CDT's tripping over this as well: java.net.URISyntaxException: Relative path in absolute URI: null:system/bsys_schedule.c at java.net.URI.checkPath(URI.java:1787) at java.net.URI.<init>(URI.java:662) at java.net.URI.<init>(URI.java:764) at org.eclipse.core.internal.filesystem.NullFileStore.toURI(NullFileStore.java:101) at org.eclipse.core.internal.localstore.FileStoreRoot.computeURI(FileStoreRoot.java:89) at org.eclipse.core.internal.localstore.FileSystemResourceManager.locationURIFor(FileSystemResourceManager.java:630) at org.eclipse.core.internal.resources.Resource.getLocationURI(Resource.java:1234) at org.eclipse.cdt.internal.core.pdom.dom.PDOMProjectIndexLocationConverter.fromInternalFormat(PDOMProjectIndexLocationConverter.java:67)
Thanks James, that patch looks good. The test had an additional assertion that failed with the fix, since it was assuming the file store hierarchy would mirror the resource hierarchy, which isn't the case for links and groups. Fix and test released in HEAD.
Thanks John!
