Menu
▾
▴
#865 Preserving local dates when unpacking files
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]
Suggested src changes partly done
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.
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
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.