Question Windows 7 idiosyncrasies

M

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
474
Points
83
Website
orbit.medphys.ucl.ac.uk
After my old orbiter development PC died a horrible death, I finally got around to buy a new one. It came with a funny OS called Windows 7 ...

Apart from the well-documented orbiter performance hit, I haven't had too many problems so far. But still, there are a few new Windows "features" that are seriously getting on my nerves.

Currently, I am battling with an apparent change of the interpretation of file modification dates in Windows 7. It seems that the dates are no longer static, but are dynamically interpreted by Windows according to time zone and daylight saving mode. As a result, when creating a 7z archive, the modification date of a file can be different between its disk and archive instances. This screws up all my packaging scripts which rely on comparing files between archive and working directory instances. Files are interpreted as different even if they are in fact identical.

Is there a way to force Windows 7 to return to the old (XP) version of interpreting modification dates statically? Are there any other workarounds? At the moment I can think of ony two solutions:
  • scrap the beta diff packages and only upload full betas (rather wasteful)
  • in the future, work on Orbiter only in Winter, so that windows 7 can't sneak in its daylight savings offset
 
Last edited:
What about just doing a diff on each pair of files instead of checking the dates? That way it will compare actual file content and not care about the dates. You can use the fc.exe command built-in to Windows. For example:

Code: 
@echo off
rem redirect output to NUL to swallow the comparison output we don't care about
fc /b %1 %2 >nul
rem condition below is true if previous command's exit code is >= 1
if errorlevel 1 goto nomatch
echo Files match!
goto :eof

:nomatch
echo Files don't match!

The "/b" switch tells FC to do a binary compare instead of a text compare.
 
I'd suggest using a DVCS. Modern DVCS compression algorithms are very close to rsync capabilities and minimize bandwidth, even for binary files. In addition, you get versioning and nice review features (diff).

I know that this looks like overhead "just" for deployment, but I bet you'll find yourself not letting it go anymore once you tried it.

regards,
Face
 
What do you write your scripts in?

Basically, you need to convert the time stamps to UTC, then compare. In Win 7 it's likely the TzSpecificLocalTimeToSystemTime function.

Don't know the details - i use total commander, and it handles 1 hour offsets internally.

I also agree with dbeachy1 that by-content comparison would be more useful and precise than by-time one.
 
martins said:
...Files are interpreted as different even if they are in fact identical....[/LIST]
Click to expand...

There is a freeware tool that could be useful for comparing folders and files even if different in names and dates:

http://www.clonespy.de/?Features

---------- Post added at 10:29 ---------- Previous post was at 10:19 ----------
RS-232 said:
You could make a dual boot PC system. (having both windows xp and 7 on same pc)
http://www.howtogeek.com/howto/8790/dual-boot-your-pre-installed-windows-7-computer-with-xp/

EDIT: You could also use a external USB Drive with windows xp on it. ...
Click to expand...

My old BartPE Boot CD doesn't work anymore on my new Win7 PC. I had to create a new multiboot USB key with a new set of tool , programs & OS (image, recovery, linux, etc.).
 
martins said:
After my old orbiter development PC died a horrible death, I finally got around to buy a new one. It came with a funny OS called Windows 7 ...

Apart from the well-documented orbiter performance hit, I haven't had too many problems so far. But still, there are a few new Windows "features" that are seriously getting on my nerves.

Currently, I am battling with an apparent change of the interpretation of file modification dates in Windows 7. It seems that the dates are no longer static, but are dynamically interpreted by Windows according to time zone and daylight saving mode. As a result, when creating a 7z archive, the modification date of a file can be different between its disk and archive instances. This screws up all my packaging scripts which rely on comparing files between archive and working directory instances. Files are interpreted as different even if they are in fact identical.


Is there a way to force Windows 7 to return to the old (XP) version of interpreting modification dates statically? Are there any other workarounds? At the moment I can think of ony two solutions:
  • scrap the beta diff packages and only upload full betas (rather wasteful)
  • in the future, work on Orbiter only in Winter, so that windows 7 can't sneak in its daylight savings offset
Click to expand...
It sounds like you're referring to this:
http://support.microsoft.com/kb/129574

I'm not sure why this would be different from your experience on XP, given that it's worked like that since NT.

There seems to be a library that offers a fix for this up on codeproject:
http://www.codeproject.com/KB/datetime/dstbugs.aspx?df=100&forumid=2218&exp=0&select=229121

but I can't help but think that there's got to be a simpler solution...
 
Hielor said:
I'm not sure why this would be different from your experience on XP, given that it's worked like that since NT.
Click to expand...

Yes, that has me confused as well. In particular, since according to the documentation, the 7z archive format also supports the UTC modification date. So I can't really imagine why the date changes for files in the archive. (unless 7zip hasn't realised that it's still summer in the UK ;) ).

Anyway, maybe I do have to switch to a more elaborate file comparison method, as suggested in this thread. I do of course use a revision control system (SVN) for my sources, but so far I've relied on the simple "7z -u" method to build the beta diff packages. Which was convenient since it provided all I needed in a single command line. Unfortunately 7z doesn't compare the actual files, just the dates.
 
martins said:
Yes, that has me confused as well. In particular, since according to the documentation, the 7z archive format also supports the UTC modification date. So I can't really imagine why the date changes for files in the archive. (unless 7zip hasn't realised that it's still summer in the UK ;) ).

Anyway, maybe I do have to switch to a more elaborate file comparison method, as suggested in this thread. I do of course use a revision control system (SVN) for my sources, but so far I've relied on the simple "7z -u" method to build the beta diff packages. Which was convenient since it provided all I needed in a single command line. Unfortunately 7z doesn't compare the actual files, just the dates.
Click to expand...

You could still use SVN for that, not sure if the 1.7 has this already as plain command line tool, but you could of course also use SVN for getting a list of files changed since a given tag.
 
martins said:
I do of course use a revision control system (SVN) for my sources, but so far I've relied on the simple "7z -u" method to build the beta diff packages. Which was convenient since it provided all I needed in a single command line. Unfortunately 7z doesn't compare the actual files, just the dates.
Click to expand...

Well, SVN is no DVCS, and as such using it as a way to deploy a Orbiter installation is more a pain than a blessing. In addition, its storage system is not exactly efficient (at least pre-1.7). In this light your decision to use 7zip was certainly the better choice.

But what about using a DVCS like Git or Mercurial for the Orbiter installation itself, without the source? You can mix it with your already established SVN checkout, and it should be fairly easy to setup a repository on a public place you can "push" to to get the newest betas out. Developers can then either use whatever system you use to "pull" the newest state, or the (now almost obligatory) zip download mechanism.

If you did 2 steps before (invoke your 7zip-script, upload the zip), it would be 2 steps with such a system, too: commit the new state, "push" the changes to the public place.

That said, maybe an rsync approach would be even better in this regards. AFAIK, rsync is pretty clever about saving bandwidth, but of course it would need an appropriate server to support it.

regards,
Face
 
Hm, the plot thickens. I have experimentally pushed my system date forward by two days (i.e. beyond BST). Now the modification dates in the 7z archive shift by one hour as expected, but the modification dates in the directory listing don't (!), meaning they agree again.

There is definitely a bug there somewhere. Either 7zip isn't using the correct system calls to compute its modification dates, or Windows doesn't use the same method in its API and in explorer.

It would be nice if Windows provided an option to display the raw UTC dates directly, rather than adding a dynamic offset. Maybe a suggestion for Windows 8?
 
i would suggest the mac, BUT seeing as how orbiter is windows dependent...there has to be a way to make win7 diplay the UTC dates, without messing with 'proprietary' information/code. Perhaps turning off the Daylight Savings time option is the solution...
 
martins said:
Hm, the plot thickens. I have experimentally pushed my system date forward by two days (i.e. beyond BST). Now the modification dates in the 7z archive shift by one hour as expected, but the modification dates in the directory listing don't (!), meaning they agree again.
Click to expand...

You mean, Explorer's dates don't take any notice of DST? Surely that's a bug?
 
Xyon said:
You mean, Explorer's dates don't take any notice of DST? Surely that's a bug?
Click to expand...
I think he means that the displayed dates in explorer for files created before the DST change didn't change, which is what I'd expect...

This sounds more like a bug in 7zip, to be honest...
 
Hielor said:
I think he means that the displayed dates in explorer for files created before the DST change didn't change, which is what I'd expect...

This sounds more like a bug in 7zip, to be honest...
Click to expand...

Ah, that makes more sense.
 
Ripley said:
7-zip is on Surceforge, as Orbiter beta...
Can't Martin just suggest to have a look at this thread to his...Surceforge colleagues??
Click to expand...

There is already a bunch of issues about timestamps with 7zip, although nothing really similar: http://sourceforge.net/search/?grou...earch=artifact&group_id=14481&words=timestamp

Sourceforge colleagues are related to each other almost like C++ developers: same framework, nothing more. It is not like we go out together every Saturday and have a beer or some such...

OTOH, placing a bug-report there might help, although I can imagine that a "patches welcome" reply is possible.

regards,
Face
 
Face said:
There is already a bunch of issues about timestamps with 7zip, although nothing really similar: http://sourceforge.net/search/?grou...earch=artifact&group_id=14481&words=timestamp

Sourceforge colleagues are related to each other almost like C++ developers: same framework, nothing more. It is not like we go out together every Saturday and have a beer or some such...
regards,
Face
Click to expand...

so there isnt a secret society?

a quick bug report would make the problem known, but it wouldnt immediately fix the problem
 
You must log in or register to reply here.

Similar threads

Mark Rober Fan
  • Sticky
Tutorial [Resource] Orbiter 2016 – Verified Download Mirrors (Wayback + Forum Archive)
Replies
6
Views
9K
Mark Rober Fan
Mark Rober Fan
dgatsoulis
Project Orbiter MediaPlayerMFD open for testing [CLOSED]
Replies
12
Views
5K
dgatsoulis
dgatsoulis
dgatsoulis
Project TrajectoryOptimizerMFD open for testing
Replies
16
Views
5K
drgullen
D
misha.physics
Linux Mint Updating
Replies
9
Views
3K
misha.physics
misha.physics
Adrian
Software Orbiter launcher taking ages to load (sometimes)
Replies
9
Views
4K
Urwumpe
Urwumpe
Back
Top