Every couple of days (2 times a week) a desktop (Win. 7) starts up with my date-time updated. The time, date & month is correct but in year 8113. This makes several programs like Word/Excel working inappropriate & crashing.
BIOS/CMOS battery has been replaced, several antivirus programs had scanned & find find any virusses. No malware or suspicious software is installed.
Does it sounds familiar to someone ?
I would appreciate any help or advice.
Thanks !
I know you would probably like an answer that tackles the origin of your problem. Unfortunately I don't see where this could come from.
Instead, I wanted to suggest that you check your time-synchronization. Windows can sync with time servers and does so in a predefined interval.
You could try to change the time-server and to change the interval.
The time-server can be changed like this:
http://mintywhite.com/windows-7/7maintenance/windows-seven-7-sync-system-clock-with-internet-time-how-to/
The interval has to be changed by altering a registry key, namely
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
\TimeProviders\NtpClient
(It is in seconds, so 86400 is the value for an interval of 1 day!).
Maybe it's not a fix of the originating problem, but frequent updates of your system time should reduce the resulting problems.
Related
We have a NetApps FAS2040 device with a Snaplock compliance volume configure. Image files are written to the volume using IBM FileNet for compliant storage of scanned post.
We want to replace the FileNet element with a in-house solution where we write the images ourselves to the volume. What I would like to know is what is involved in doing this.
Is it just a case of writing a file to the volume then setting the read only attribute to true?. How would I configure expiration for the file. Can I change the time between it being read only and then permanently committed?
Thanks
Stuart
Setting a file read only will activate the snaplock. It will default to the default snaplock retention period - which is configured on your filer.
Usually this is set to a short interval, to avoid accidentally snaplocking junk for protracted periods of time. There's really nothing more annoying than accidentally locking a 100TB aggregate for 3 years.
You update the individual file retention by setting an access time. By default, when you set a file read only, the atime will be set to now + the default retention.
You can update this to a longer timespan (but never shorter) via the touch command:
touch -a -t 201411210000 <filename>
(note - iso date format. YYYYMMDDHHmm)
You can use the stat command to show you the retention dates.
The whole process is geared off the snaplock compliance clock - it's a tamper resistant clock, which should generally match 'real time' but there are a variety of circumstances where it won't. E.g. if you've powered the filer down, or the volumes or whatever, you can't reset the clock, forward date and mess with snaplock. It will adjust itself by up to a week per year, but NO FASTER.
Once the atime is less than the value on the snaplock clock, you can then delete the file (but note - not modify it).
You can set snaplock.autocommit_period to automatically snaplock files that have been static for the defined period.
I would very strongly recommend thinking hard about snaplock retention periods. Setting this to years will almost certainly cause you grief, when you realise you need to do some essential maintenance and you can't because snaplock is in the way. You can only delete an aggregate once every piece of data in it has had the clock expire. (And if any has been offline ever, the clock will be skewed too). That means years after your system is end of life, it will not be usable for anything other than watching the clock tick.
I would suggest instead that you consider a mechanism to refresh snaplock on a periodic basis - e.g. set the retention for 6 months. Run a monthly cronjob to update it and add another month.
You cannot change the time between "read only" and "permanently committed" because that's not the way it works. As soon as it's read only, it's snaplocked. But as said - the retention period should hopefully default to a sensible number.
I have a vb6 program installed on thousands of machines, some XP and some Win7. A Win7 user has called to say that the time the program applies to its events is one hour earlier than the time on the laptop clock, which is correct. It is set to the correct time zone (Eastern) and to daylight savings time adjustment, which is the way my own Win7 machine is set up (and my own machine does not have this problem).
The line of code that obtains this time in VB6 is:
.IssueDate = Now
to put the current time and date into a member variable.
Does anyone have any ideas why a particular machine would be off by one hour, given that the clock is displaying the correct time and the time zone and DST adjustment appear correct?
I'm going to mark this one 'answered' and move on. I asked my user, diffidently, to reboot, not really expecting it to do anything; he did and said the test case he ran did not show the error. I asked him to call me the next time he used the system for its full-blown purpose, but he hasn't done so. My current suspicion is that the PC clock was off by an hour for a period this morning and he didn't notice it, he only noticed the time on the documents the application was producing.
I have a page displayed in classic ASP. 90% of the time the dates on the page show on users' machines as MM/DD/YY - same as the international settings in the registry for short date format. About 10% of the time this gets switched around and is presented as DD/MM/YY. After a restart of the machine MM/DD/YY is displayed again.
I assume some process has run which is changing the default date format. Any ideas on what I can do to a.) diagnose which program may be changing the date format and b.) how to ensure the default format is in place before loading my page?
Thanks in advance for your help.
This has to do with the complicated way that IIS and Windows are trying to figure out the "default" way to specify the date since you haven't explicitly set it in the code.
You can read more here on MSFT about the date format randomly changing.
You said a reboot fixes it, which to me implies someone is logging on to the machine and that person has a different date format. The reboot kicks them off, and it reverts back.
The workaround is just to set your date format explicitly in the code, but that's a different question.
I am using VB6 SP6
This code has work correctly for years but I am now having a problem on a WIN7 to WIN7 network. It also works correctly on an XP to Win7 network.
Open file for random as ChannelNum LEN =90
'the file is on the other computer on the network
RecNum = (LOF(ChannelNum) \ 90) + 2
Put ChannelNum, RecNum, MyAcFile
'(MyAcFile is UDT that is less than 90 long)
.......... other code that does not reference file or RecNum - then
RecNum = (LOF(ChannelNum) \ 90) + 2
Put ChannelNum, RecNum, MyAcFile
Close ChannelNum
The second record overwrites the first.
We had a similar problem in the past with OpportunisticLocking so we turn that off at install - along with some other keys that cause errors in data in Windows networks.
However we have had no problems like this for years, so I think MS have some new "better" option that they think will "improve" networking.
Thanks for your help
I doubt there is any "bug" here except in your approach. The file metadata that LOF() interrogates is not meant to be updated immediately by simple writes. A delay seems like a silly idea, prone to occasional failure unless a very long delay is used and sapping performance at best. Even close/reopen can be iffy: VB6's Close statement is an async operation. That's why the Reset statement exists.
This is also why things like FlushFileBuffers() and SetEndOfFile() exist at the API level. They are also relatively expensive operations from a performance standpoint.
Track your records yourself. Only rely on LOF() if necessary after you first open the file.
Hmmm... is file (as per in the open statement at the top of the code sample) UNC filename or similar to x:\ where x is the mapped drive? Are you not incrementing RecNum? Judging by the code, the RecNum is unchanged and hence appears to overwrite the first record...Sorry for sounding ummm no pun intended... basic...It would be of help to show some more code here...
Hope this helps,
Best regards,
Tom.
It can be just timing issue. In some runs your LOF() function returns more updated information than in other runs. The file system API is asynchronous, for example when some write function is called it will not be immediately reflected as the increazed size.
In short: you code have shown an old bug, which is just easier to reproduce on Windows 7.
To fix the bug the cheapest way: you may decide to add a delay (it can be significant delay of say 5 seconds).
More elaborate fix is to force the size update by closing and reopening file.
I have a program that uses save files. It needs to load the newest save file, but fall back on the next newest if that one is unavailable or corrupted. Can I use the windows file creation timestamp to tell the order of when they were created, or is this unreliable? I am asking because the "changed" timestamps seem unreliable. I can embed the creation time/date in the name if I have to, but it would be easier to use the file system dates if possible.
If you have a directory full of arbitrary and randomly named files and 'time' is the only factor, it may be more pointful to establish a filename that matches the timestamp to eliminate need for using tools to view it.
2008_12_31_24_60_60_1000
Would be my recommendation for a flatfile system.
Sometimes if you have a lot of files, you may want to group them, ie:
2008/
2008/12/
2008/12/31
2008/12/31/00-12/
2008/12/31/13-24/24_60_60_1000
or something larger
2008/
2008/12_31/
etc etc etc.
( Moreover, if you're not embedding the time, what is your other distinguishing characteritics, you cant have a null file name, and creating monotonically increasing sequences is way harder ? need info )
What do you mean by "reliable"? When you create a file, it gets a timestamp, and that works. Now, the resolution of that timestamp is not necessarily high -- on FAT16 it was 2 seconds, I think. On FAT32 and NTFS it probably is 1 second. So if you are saving your files at a rate of less then one per second, you should be good there. Keep in mind, that user can change the timestamp value arbitrarily. If you are concerned about that, you'll have to embed the timestamp into the file itself (although in my opinion that would be ovekill)
Of course if the user of the machine is an administrator, they can set the current time to whatever they want it to be, and the system will happily timestamp files with that time.
So it all depends on what you're trying to do with the information.
Windows timestamps are in UTC. So if your timezone changes (ie. when daylight savings starts or ends) the timestamp will move forward/back an hour. Apart from that, and the accuracy of about 2 seconds, there is no reason to think that the timestamps are invalid, and its certainly ok to use them. But I think its bad practice, when you can simply put the timestamp in the name, or in the file itself even.
What if the system time is changed for some reason? It seems handy, but perhaps some other version number counting up would be better.
Added: A similar question, but with databases, here.
I faced some issues with created time of a file after deletion and recreation under same name.
Something similar to this comment in GetFileInfoEx docs
Problem getting correct Creation Time after file was recreated
I tried to use GetFileAttributesEx and then get ftCreationTime field of
the resulting WIN32_FILE_ATTRIBUTE_DATA structure. It works just fine
at first, but after I delete file and recreate again, it keeps giving
me the original already incorrect value until I restart the process
again. The same problem happens for FindFirstFile API, as well. I use
Window 2003.
this is said to be related to something called tunnelling
try usining this when you want to rename the file
Path.Combine(ArchivedPath, currentDate + " " + fileInfo.Name))