Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 293235

Summary: [backport][Import/Export] Timestamps updated on archive export and on project import
Product: [Eclipse Project] Platform Reporter: Prakash Rangaraj <prakash>
Component: UIAssignee: Prakash Rangaraj <prakash>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: bokowski, christophe.bismuth, deboer, mober.at+eclipse, wb-rel
Version: 3.5.1   
Target Milestone: 3.5.2   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Bug Depends on: 263305    
Bug Blocks:    

Description Prakash Rangaraj CLA 2009-10-24 05:45:32 EDT 
+++ This bug was initially created as a clone of Bug #263305 +++

FWIW, I figured this would have been asked/reported already, but couldn't find
any dups by searching.

When you export via Archive File, the timestamp of all the files in the archive
is set to the current time, regardless of the local timestamp on disk.
Likewise, importing back from the archive via Existing Projects into Workspace
sets the timestamp of all files to the time of import.

There's nothing broken by this behaviour, but it is annoying from a development
perspective. If someone sends me a zip of their projects, everything is "new"
and there is no quick or easy way to tell what has been recently changed. If
you use zip files as a way to exchange information, you really need a binary
comparison tool in addition to Eclipse.

Is there any reason for this behaviour? If not, please preserve timestamps on
export, and preferably import too. If there is a reason to keep the current
behaviour, this could be provided as an optional setting in the wizard.
Comment 1 Martin Oberhuber CLA 2009-11-24 07:40:18 EST 
This bug is for tracking the backport of the fix in bug 263305, which supports maintaining original file attributes and time stamps on import/export to archive files, to Eclipse 3.5.2.
Comment 2 Prakash Rangaraj CLA 2009-11-30 11:53:27 EST 
Boris,

    The patch is available in the original bug (attachment# 124648 [details]). Need your approval for checking it to 3.5 branch.
Comment 3 Boris Bokowski CLA 2009-11-30 12:07:53 EST 
Prakash, do all the APIs involved agree with respect to their notion of "time"? Is there a possibility to get it wrong with multiple time zones, or summer time/winter time changes?
Comment 4 Martin Oberhuber CLA 2009-11-30 14:11:49 EST 
I did a quick check and according to their API docs, all the used API calls are in sync referring to "Java time". As in the patch on bug 263305:

/** milliseconds since the epoch (00:00:00 GMT, January 1, 1970) */
long java.io.File#lastModified();

/** seconds since January 1st 1970 */
long org.eclipse.ui.internal.wizards.datatransfer.TarEntry#getTime()

/** modification time of the entry. 
 *  Converts DOS time to Java time (number of milliseconds since epoch).
 */
long java.util.zip.ZipEntry.getTime()

/** number of milliseconds since the epoch (00:00:00 GMT, January 1, 1970) */
org.eclipse.core.resources.IResource#setLocalTimeStamp(long);
Comment 5 Boris Bokowski CLA 2009-12-01 14:48:20 EST 
One last question from the department of the overcautious: Does this have a noticeable performance impact?

If not, +1 for putting the fix in 3.5.2.
Comment 6 Prakash Rangaraj CLA 2009-12-01 23:43:20 EST 
(In reply to comment #5)
> One last question from the department of the overcautious: Does this have a
> noticeable performance impact?

  :-) Not that I know of. A glimpse at the patch doesn't show any. I tried few samples and didn't notice any difference.
Comment 7 Martin Oberhuber CLA 2009-12-02 16:46:04 EST 
(In reply to comment #5)
> One last question from the department of the overcautious: Does this have a
> noticeable performance impact?

Not with a sane file system, I would say, since applying file attributes should always be a lot faster than reading/writing file contents. And now that bug 296647 is fixed, I guess that the Eclipse File System is sane (again). :)
Comment 8 Boris Bokowski CLA 2010-01-07 00:01:55 EST 
+1 for 3.5.2
Comment 9 Boris Bokowski CLA 2010-01-11 08:58:15 EST 
Prakash, can you please commit this change in time for the next M build?
Comment 10 Prakash Rangaraj CLA 2010-01-12 00:53:16 EST 
Patch released to Maint stream
Comment 11 Prakash Rangaraj CLA 2010-01-21 03:51:21 EST 
Verified in M20100120-0800