[NSIS-Bugs] [ nsis-Bugs-2581469 ] Preserving local dates when unpacking files

[SourceForge.net <no...@so...>]

Bugs item #2581469, was opened at 2009-02-09 06:52
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=373085&aid=2581469&group_id=22049

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: daveb (daveb491)
Assigned to: Nobody/Anonymous (nobody)
Summary: Preserving local dates when unpacking files

Initial Comment:
In 2003 we patched v2.0b3 of NSIS to fix a problem we were having when unpacking files in different timezones.
Our software uses filetimes to determine if imported data is up to date, storing the filetime as data whenever a file contains information read and cached from another file.
So it is particularly important that we maintain consistency in a set of files packaged up in one timezone then unpacked in another. We do not want the system time to be converted due to timezone changes.
We made a relatively simple change, which I carefully documented and we have been using this old version successfully for the last 5 years.

This behaviour may not be what everyone wants, but if put into NSIS as an option, it would be a potentially useful thing for others.
So I was looking at the latest version 2.43 and thought it might be a good idea to make the change in the new version, and contribute this to the project for the benefit of others. It has been working flawlessly for us for many years.

Now trying to make the change to the new version, things are done slightly differently, and I was hoping some expert with current knowledge might be able to help with this, and perhaps put it into the project properly. I am not familiar enough with the SourceForge protocol to take this on properly and try to edit the project source myself. So I have made a start by trying to put the changes in as best I can, and zipped up the files before and after for comparison, and also included the original notes and differences.

I have not attempted to make it optional behaviour, and one of the four changes is not done at all, but this is just the NSIS_VERSION change. This would happen anyhow if merged into the current SourceForge development properly.

[see also http://forums.winamp.com/showthread.php?s=&postid=2483420#post2483420 where it was suggested I put this here]

----------------------------------------------------------------------

Comment By: https://www.google.com/accounts ()
Date: 2010-07-02 18:53

Message:
I'll note that we're redistributing Python files and running into this as
well. We've probably been encountering it for a while, but only now
noticed.

Basically, we have .py files which build .pyc or .pyo files. The files
contain the timestamp that they were built from, so that python knows if
the compiled file is out of date. It uses an exact comparison (mtime ==
cached_value), so any skew causes the file to appear out of date.

----------------------------------------------------------------------

Comment By: daveb (daveb491)
Date: 2009-02-09 07:03

Message:
Further notes on this....

The problem we have is that the person packing the files is in a different
timezone to the person unpacking. We were using both FAT and NTFS, but
these days mostly NTFS.

In more detail... here's an example of the problem:
Distribute files A,B,...
Because A contains some data imported from B, data in A also contains the
timestamp of B internally.
eg A contains data for B and timestamp B at say "1Feb09,1300"
Pack it all up and distribute.
Now end user unpacks files and tries to use them, but NSIS when unpacking
notes timezone change and creates A and B files with adjusted times. So
perhaps timestamp of B is now "1Feb09,1800". This now fails to match
recorded timestamp in A and application decides incorrectly that imported
data needs updating.

We used to pack and unpack files using WinZip. It saves and restores local
time, so we devised a timezone invariant C++ class which serialized so that
restored data for these timestamps was the same value regardless of
timezone. Everything then worked fine as files got shipped across timezones
in zips. But for real installs as opposed to little zip updates, we began
to use NSIS, and that's when we struck this problem. As I said, we fixed it
in the little customization of 2.0b3 that I attached above.

Could be that WinZip is not doing "the right thing", but it is hard to
argue the rights and wrongs here. Should the filetimes be adjusted or not?
Since WinZip is so all pervasive, it would seem to me a good idea to make
this behaviour optional, but if compulsory, I would rather stay in line
with WinZip behaviour where if the file says time=1500 when you pack it up,
it will still say 1500 when you unpack it, regardless of timezone.

Hope this clarifies the problem anyhow... thanks.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=373085&aid=2581469&group_id=22049