Community
Participate
Working Groups
Creating a Project (simple or otherwise) and importing files into it using the import->File System wizard takes away the executable permission from the imported exec files.
*** Bug 25748 has been marked as a duplicate of this bug. ***
org.eclipse.ui.wizards.datatransfer.ImportOperation.importFile() calls IFile.create which creates a new file at the destination with the default flags set. Moving to Platform/UI for comment. Please let us know if new API is required in Core to make this work correctly. Thanks.
The problem here is the conversion to an org.eclipse.core.internal.resources.File from a java.io.File. We would need API that can create an org.eclipse.core.internal.resources.File directly from an IFile so as to preserve the flags.
Note that in addition to losing the executable bit, importing from the filesystem also loses the mtime of every file it copies. If you later do a cvs update in this directory (say by using Team->Share Project), every file will be sent to the server. This causes problems for people with slow links.
*** Bug 2106 has been marked as a duplicate of this bug. ***
*** Bug 28147 has been marked as a duplicate of this bug. ***
Appending comments from PR 28147... Simon Archer... When you import files into your Eclipse workspace, typically from a zip or a jar, Eclipse does NOT respect the timestamps of these files. The files are created "new", using the current time/date as the timestamp. We have seen that this can cause "identity" concerns for the VCM component. I could imagine this causing problems for other tools such as make/Ant, which possibly also depend upon timestamps. Since other tools, such as WinZip, do respect the timestamps of files, you could extract the files into your workspace and "refresh". But clearly this is not the ideal approach for Eclipse or its users. Kevin McGuire... Note that this is important for CVS scenarios where the user is unzipping over an existing project tree under source management. The net result is that all the files look dirty. Even CVS aside, it loses important information that the user may require (the original file timestamp). I've up'ed the severity because I think this should be addressed for 2.1.
Investigate for 2.1. There doesn't seem to be any way of setting the creation time in java.io. You can set the last modified time using File.setLastModified(long). Perhaps this would be good enough. DJ, does Core base its timestamp off of File.getLastModified() (it doesn't look like there are any other possibilities)?
Jar import in JDT would have to do the same.
Yes, we use the last modified timestamp (rather than creation, etc). Although the number that we get from the filesystem may be different than the one returned from java.io.File.getLastModified() because we are using our natives.
If creation time turns out to be important, we could always piggyback on the core natives to get/set this. Could also look at java.nio (new I/O), although this would add to our footprint.
*** Bug 30001 has been marked as a duplicate of this bug. ***
Moving to component owner as the required work from Core has been marked for later.
As a workaround, you can use cp or unzip into the project location, then refresh the project. There are no plans for the UI team to work on this defect until higher priority items are addressed. If you would like to work on this defect, please let us know on the platform-ui-dev mailing list.
Understood. Still a number of people have encountered this and I think it should be worked on. Four duplicates that I know of.
This bug needs attention before we can successfully implement the RPM manupulation plugin we are working on. Both the timestamp issue and the permissions issue affect the importing/exporting of source RPMs. Having the timestamps changed definitely has a negative affect on how "make" tries to build a project in some circumstances.
We cannot move forward on this until Bug 26100 is resolved. If you would like you can reopen 26100.
Rick, are you copying from another location in the filesystem, or from a zip or jar? Either way, JDK 1.3 and 1.4 do not have the support needed to preserve permissions. See bug 26100 for details. Can you work around the problem, as suggested in comment #14?
Nick, Following up from Rick's comment, the SRPM import allows you to choose the files you want to import, much like Filesystem import. So while unzip or tar'ing into the project directory might work for the whole project, I'm not sure what we can do with the partial selection. We could I suppose untar into the project directory, and then remove the files the user did not want; but that would be a temporary solution at best. Point taken about the JDK 1.3/1.4 not having methods to support - I'm not sure what the fix would be in that light. Phil Muldoon
Don't the unzip and tar commands let you specify specific files, or lists of specific files?
The bigger problem, right now, for the RPM plugin is the modification times getting changed since it screws up "make" sometimes. Since there appears to be methods (lastModified, setLastModified) that could resolve this part, could the timestamp problems be resolved with these methods and the file permissions fixed later?
That is something that could be done as anything that the java.io support has can also be done by us. Import currently creates a new file and then uses a stream to move the contents (as there is no copy API).
It depends on whether you're copying from files or from a zip/jar. java.util.zip.ZipEntry does not have API to obtain the modification time, although it may be possible to extract it from the "extra" info. The format for this is zip-tool-specific though. It would also be strange to preserve the modification stamp but not the creation stamp.
Right now the source RPM import works just like the "Filesystem import" feature. Basically we install and build a source RPM in a work area and the path to the work area gets passed back to the GUI and from then on is treated as a filesystem where you can select/deselect individual files to import. The final method we call to import it is: importResources(fileSystemObjects) which eventually does what Tod said, creates a new file and copies it using a stream. I agree, it would be strange to maintain modification times and not permissions. We are investigating other ways to handle this now. Thanks for all of your input.
Created attachment 5141 [details] Proposed patch Here is a patch to org.eclipse.ui.workbench that keeps the timestamp. Please let us know if this is useful.
Has this been incorporated into the latest drop of eclipse?
No it has not.
When will the fix be incorporated into Eclipse?
This is not currently in the 3.0 plan.
From Steve This will need JRE 1.5 support and some prereq work in bug 26100 that has been marked for later. Tod, please mark the resolution of this one for later.
This is going to be revisited as part of an attempt to get Bug 26100 fixed.
*** Bug 68238 has been marked as a duplicate of this bug. ***
Now that the base support is ready we can look into doing this - as this is a popular item if anyone has a suggested patch I would be happy to review it. Doug please correct if I am wrong about being able to move forward on this.
IResource.getResourceAttributes(); IResource.setResourceAttributes(ResourceAttributes);
The main issue here is the mapping from java.io.File which does not have API for many of these permissions (executable being the most important one). I'm not sure how we would determine this using Java.
I have added a new factory method, ResourceAttributes.fromFile, to create a resource attributes instance with values compute from the specified file in the file system. This can be used by import to obtain and set the correct permissions.
The ImportOperation now supports whatever ResourceAttributes supports which is the archive, read-only and executable flags. On Linux it looks as though it only keeps user permissions not group or others. I am going to close this bug as any other attributes we get will be from changes to ResourceAttributes which will be transparent to the import operation.
Verified in 20050512
