Community
Participate
Working Groups
Version: 3.5.0 Build id: I20090512-2000 After importing a remote directory in which files exist differentiated only by case into a project, all instances of said files will be overwritten with the last such file in the directory listing. Remote copies are unaffected. 1. Create a new local project in Java perspective. 2. Switch to RSE perspective. In a folder in a unix-based remote system, create 'test.txt' and 'TEST.txt' 3. Right click the folder, and select 'Import into Project' 4. View the project in the Package Explorer in the Java perspective. Note that only TEST.txt has been imported. This effect is also reproducible with case-differentiated-only folders. Folder contents will be merged and overwritten.
Created attachment 136053 [details] patch with case check and display of message Could you try with this patch?
Patch generates warning, only imports first-listed file. Suitably addresses issue, but does not resolve it; however, it should be sufficient to motivate users to resolve conflict manually.
(In reply to comment #2) > Patch generates warning, only imports first-listed file. Suitably addresses > issue, but does not resolve it; however, it should be sufficient to motivate > users to resolve conflict manually. > From my tests, it looks like all listed files are attempted on the import. Are you saying that only the first-listed file is imported or just that the first failed import is shown?
I was noting that only the first-listed file is imported, whereas previously the action overwrote without prompting, effectively importing only the last-listed file. Failure notices are generated as expected, and in my tests, all files were attempted. From what I see, failure notices do not conflict with uniquely-named files listed after the case-differentiated-only ones. The patch does what it should.
(In reply to comment #4) > I was noting that only the first-listed file is imported, whereas previously > the action overwrote without prompting, effectively importing only the > last-listed file. Failure notices are generated as expected, and in my tests, > all files were attempted. From what I see, failure notices do not conflict with > uniquely-named files listed after the case-differentiated-only ones. The patch > does what it should. > Okay. Improvements could also be made to display multiple conflicts - since right now only the first conflict is displayed. Since RSE 3.1 has past it's UI-freeze, that part will have to wait. I'll commit the current patch to cvs.
I've committed the fix.
Since we are in RC endgame, this fix will need another commiter's +1 before it can be released. See bug 276103 for a discussion.
I cannot approve the use of org.eclipse.core.internal.resources non-API in RemoteFileImportOperation. We are bound to using public API only per Galileo Requirement, and clean up our technical debt rather than introducing new one. Isn't there an official way for finding out whether a file exists?
Created attachment 137492 [details] patch that checks for existance without using internal.resources How about this approach instead? I am referencing an internal message from our own files.core plugin but at least it's our own.
I've committed the updated patch to cvs.
New patch looks better, but what if a FOLDER with same name but different case already exists? For instance: Foo/ Bar/ test.txt bar Shouldn't this be reported as an error es well on import? Also, what happens when exporting from case-sensitive file system to a case-insensitive one? I'm not necessarily in favor of changing all code for this now, but we should be aware of potential problems and decide what's the right thing to do. In case of the issue mentioned above, I think the existingFileInDifferentCase(IFile) method should likely better return an IResource (which can also be an IFolder) in case a name clash is detected. Please be sure to test the scenario.
(In reply to comment #11) > New patch looks better, but what if a FOLDER with same name but different case > already exists? For instance: > > Foo/ > Bar/ > test.txt > bar > > Shouldn't this be reported as an error es well on import? Also, what happens > when exporting from case-sensitive file system to a case-insensitive one? > > I'm not necessarily in favor of changing all code for this now, but we should > be aware of potential problems and decide what's the right thing to do. > > In case of the issue mentioned above, I think the > existingFileInDifferentCase(IFile) > method should likely better return an IResource (which can also be an IFolder) > in case a name clash is detected. > > Please be sure to test the scenario. > I created the following structure: FLD/abc.c fld/test.txt When I try to import it, I get the following message: Unexpected exception received: Unable to import /home/dmcknigh/111/fld/test.txt: A resource exists with a different case: '/local/FLD'.. To compare with Eclipse, I created a local archive with the following structure: FLD1/test.txt fld1/test2.txt When I try to import it via the Archive file import wizard, I get the following message: Problems were encountered during import: Unable to import fld1/test2.txt. Reason: A resource exists with a different case: '/local/FLD1'. So the behaviour is more or less the same.
(In reply to comment #12) Interesting. Looking at the code, I cannot see how it would detect fld versus FLD on remote imort, can you? Did you also try folder ("fld") versus file ("FLD") ?
I'm releasing the fix into RC3 although I'd still like to understand why folder import with different case is properly reported.
(In reply to comment #13) > (In reply to comment #12) > Interesting. Looking at the code, I cannot see how it would detect fld versus > FLD on remote imort, can you? > Here's the exception we get in this case: org.eclipse.core.internal.resources.ResourceException: A resource exists with a different case: '/local/FLD'. at org.eclipse.core.internal.resources.Resource.checkDoesNotExist(Resource.java:305) at org.eclipse.core.internal.resources.Resource.checkDoesNotExist(Resource.java:283) at org.eclipse.core.internal.resources.Folder.assertCreateRequirements(Folder.java:29) at org.eclipse.core.internal.resources.Folder.create(Folder.java:88) at org.eclipse.core.internal.resources.Folder.create(Folder.java:118) at org.eclipse.rse.internal.importexport.files.RemoteFileImportOperation.createContainersFor(RemoteFileImportOperation.java:220) at org.eclipse.rse.internal.importexport.files.RemoteFileImportOperation.getDestinationContainerFor(RemoteFileImportOperation.java:410) at org.eclipse.rse.internal.importexport.files.RemoteFileImportOperation.importFile(RemoteFileImportOperation.java:464) at org.eclipse.rse.internal.importexport.files.RemoteFileImportOperation.importRecursivelyFrom(RemoteFileImportOperation.java:616) at org.eclipse.rse.internal.importexport.files.RemoteFileImportOperation.importFileSystemObjects(RemoteFileImportOperation.java:558) at org.eclipse.rse.internal.importexport.files.RemoteFileImportOperation.execute(RemoteFileImportOperation.java:305) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:104) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:116) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) > Did you also try folder ("fld") versus file ("FLD") ? > If we have a file ("FLD"), then the same exception is hit.
Interesting. Thanks for investigating!
