>>
>>It's a neat approach to the problem, Bob; I see two possible problems:
>>
>>(1) You need write access to somewhere on the NT box in question, and
>>(2) I've gotten some funny time stamp conversions reading a date/time stamp off an NTFS volume on some release of NT with some Win9x versions. The date/time stamp read off the NT box vaied by up to an hour with the date/time stamp read for the same file from a networked Win9x box. I've never pinpointed the problem, but it has resulted in a lot of head-scratching; biggest problems seem to have come up during development; I sometimes got .FXPs back from an NT box date/time stamped earlier than the .PRG file when the .FXP was compiled from the Win9x box and the .PRG modified on the NT box in the same shared NT directory.
>>
>
>Ed, could this possibly have anything to do with Daylight Savings Time? We used to see this on W95 boxes attached to an NT server when we were using FPD. After DST kicked in, all of our FPD projects would need to be recompiled or you'd get "source out of date" messages in the debugger. Everything would show as 1 hour time difference there, too.

No, it was seemingly random, and the time variations were in the 26-27 minute range. I haven't seen the problem since we switched to SP4 on our NT Server, so it might have been a bug with how the time stamp got sent back. It wasn't consistent enough (or important enough) to really track down. And since we sync the time for our systems during login, I'm fairly certain it wasn't DST conversipon that did it.