winxp dashboard dependent on system datetime?

hi i noticed what seems to be a repeatable pattern when i have my drobos connected with dashboard, when i change the dat/time to some time in the past.

eg there is a free util called “tip” which steve from grc made to help check iomega zipdisks and to keep them in good shape, but unfortunately he timecoded the program to only work up to a particular date of january 2010.
(he said hed release a new version with an extended date but hasnt got round to it yet so suggested backdating the system clock)

but, my drobo(s) start having mft or delayed errors and often the dashboard soon after about 30-90mins shows the “no drobos found” icon, and sometimes the whole system freezes/crashes.

so i was wondering, does the dashboard and ddservice actually heavily rely on the system date, and how would this affect things on normal date changing, such as daylight savings)?

so far i just use my computer the normal way, change the date and use tip (and then run into some problems somewhere down the line)

should i just exit the dashboard before backdating?
or should i use dashboard to put them both in to standby mode before backdating?
or use dashboard for putting into standby, and then also exit the dashboard before backdating?

main question is how dependent on a fixed date the drobo is?
thanks :slight_smile:

i havent tried putting them into standby mode from the dashboard[hr]
drobo seems healthy and each time it happens after backdating, i chkdsk /x al the drobos and volumes and no issues are found.
(also info on backdating came from one of steves helpers, havent spoken to the great man himself yet LOL) :slight_smile:

“normal date changing”

daylight savings or not - the time NEVER EVER goes backwards. i would imagine that computers cope by either continually using standard local time (i.e. without the adjustment - in the UK’s case everything would be in GMT at all times - even if things are displayed as BST). or simply it would know that 02:30 BST is still actually EARLIER than 01:35 GMT (i.e. it always knows what time frame the time/date is referenced in).

as for the rest, i dont know, but considering how drobo muddles up and scrambles your data, im not sure i want it being confused about what clusters were created / accessed first or last, or suddenly stumbling on parity blocks that were created in what it considers to be the future!

I really can’t imagine Dashboard having issues or interaction with the system date but… stranger things have happened.

I can tell you though, that Windows Genuine Advantage (WGA) and Windows Update are very date-aware. Changing timezones is OK, but “backdating” they do not like.

In fact, on a new Windows install when the clock may not be set correctly, Windows Update throws a really oddball error code which leads to help (if you can get it, ha ha) that says to check the system date/time.[hr]
I also know that certain things in Windows don’t like a null/empty timestamp which IIRC shows up as some date in 1970.

thanks for the info guys,
i guess it’s best to not try and confuse the system further with the drobos, just in case, and to safely disconnect them while i do the backdating shennigans… (oh if only steve gibson would simply tweak his 48kb code to allow it to run in the present day) lol

he must have struck a deal with iomega to keep a working date limit on it :slight_smile:

Hey Paul,

Maybe give this utility a try? It intercepts the date-related API calls to fool a program into running as if it was a certain date, without changing the actual system date.

thanks a lot for suggesting it.
i tried it but cant seem to get it to work.

ive tried a lot of combinations but it just wont accept it :frowning:

maybe you know a way to get it to work with this file that i dont? :slight_smile:

Hi Paul,

I got it running on my Win 7 x64 Enterprise laptop here at work. No Zip drive to test with tho, but it comes up to the point of telling me no Iomega devices are available.

Running Tip.exe directly gives me the expiration notice as expected.

Here’s what I did to get it going via RunAsDate:

  1. Download (and extract) RunAsDate (the “regular” 32-bit version not the x64 one - that one’s for x64 apps and will trigger an appcrash if you use it on Tip.exe)
  2. Run RunAsDate
  3. Drag Tip.exe into RunAsDate window (or type in the full path)
  4. Set date to December 31, 2009 (2:00 AM, shouldn’t matter as long as it’s before the Tip expiration date)
  5. Enable/Tick the Immediate Mode box (this is necessary or you’ll still get the expiration notice)
  6. Create shortcut TestTip
  7. Run TestTip shortcut
  8. It runs :slight_smile:

I unchecked the “Always ask before opening this file” box (a Vista/7 security thing) for the shortcut and it seems to stick.

thanks a lot bhiga,
it wont work on the xp machine, but your above method works a treat on the win7 laptop :slight_smile:

i should be able to do the necessary work from there using my usb zipdrive :slight_smile:

I learned a long time ago never to expect any updates from Steve Gibson. :slight_smile:

Mind if I ask why you are still using Zip disks?

You’re very welcome Paul. Other people’s problems often lead me to cool tools and toys. :slight_smile:
Perhaps I’ll retrieve my Zip disks from my parents, if they haven’t otherwise disposed of them.

dpuett - I still have a few 3.5-in floppies and a “nostalgia stack” of about 20 5.25-in floppies. I should put those in a display case, LOL!
I went through and imaged most of them via Kryoflux tho. The ones I keep (and the USB floppy drive I have) are for those rare instances when virtual floppies just won’t work, which is sometimes the case with older disk image writers, like the WDDiag floppy creator. Also helps in making things like Plop boot manager disks to allow older machines to boot from USB when they lack BIOS support to do so.

ahh still use zips as useful way to transfer between older machines having usb stick problems plus have 3 zip drive hardwares hooked up might as well use them :slight_smile:
(they are still pretty neat :slight_smile: