Guest MrTom Posted May 2, 2008 Posted May 2, 2008 A previous post made me curious about C:\_Restore\TEMP (Windows ME, of course), which I looked at and found thousands (I think about 3000) of files, some create/modified as early as 2001. I reduced the disk space for system restore and then disabled it, interspersed with a reboot or two. Then C:\_Restore\TEMP showed no files; it was empty. I then enabled system restore and did a reboot. A system checkpoint was created and I created another restore point. Now C:\_Restore\TEMP has 93 files, many with creation dates as early as 2003 and many with modified dates earlier (Feb 2008, March 2008, April 2008) than May 2008 (today's system date is May 2, 2008). What's going on with these dates? I would have expected that all 93 files should show today's date, May 2, as both the created and modified date. Tom
Guest Mike M Posted May 2, 2008 Posted May 2, 2008 Re: C:\_Restore\TEMP Don't be mislead by the file creation date. This is the date of the original archived file rather than when the file was archived. -- Mike Maltby mike.maltby@gmail.com MrTom <NotMyAddress@invalid.net> wrote: > A previous post made me curious about C:\_Restore\TEMP (Windows ME, of > course), which I looked at and found thousands (I think about 3000) of > files, some create/modified as early as 2001. I reduced the disk > space for system restore and then disabled it, interspersed with a > reboot or two. Then C:\_Restore\TEMP showed no files; it was empty. > > I then enabled system restore and did a reboot. A system checkpoint > was created and I created another restore point. Now > C:\_Restore\TEMP has 93 files, many with creation dates as early as > 2003 and many with modified dates earlier (Feb 2008, March 2008, > April 2008) than May 2008 (today's system date is May 2, 2008). > > What's going on with these dates? I would have expected that all 93 > files should show today's date, May 2, as both the created and > modified date. > > Tom
Guest MrTom Posted May 3, 2008 Posted May 3, 2008 Re: C:\_Restore\TEMP I don't understand what you mean. I asked about 93 files in C:\_Restore\TEMP that were apparently created today. How/why did many of those files get creation and modified dates earlier than today? You said "This is the date of the original archived file." Of which original archived file do you speak? Tom Mike M wrote: > Don't be mislead by the file creation date. This is the date of the > original archived file rather than when the file was archived. MrTom <NotMyAddress@invalid.net> wrote: > A previous post made me curious about C:\_Restore\TEMP (Windows ME, of > course), which I looked at and found thousands (I think about 3000) of > files, some create/modified as early as 2001. I reduced the disk > space for system restore and then disabled it, interspersed with a > reboot or two. Then C:\_Restore\TEMP showed no files; it was empty. > > I then enabled system restore and did a reboot. A system checkpoint > was created and I created another restore point. Now > C:\_Restore\TEMP has 93 files, many with creation dates as early as > 2003 and many with modified dates earlier (Feb 2008, March 2008, > April 2008) than May 2008 (today's system date is May 2, 2008). > > What's going on with these dates? I would have expected that all 93 > files should show today's date, May 2, as both the created and > modified date. > > Tom
Guest TomV Posted May 3, 2008 Posted May 3, 2008 Re: C:\_Restore\TEMP I think Mike's answer was clear. What does the system restore utility do in Windows ME? "System Restore is designed to automatically monitor and record changes made to the core Windows system files and to the registry." The dates you're seeing are the dates of the original files not the date(s) system restore created the archived files. Now where did I read that before? MrTom wrote: > I don't understand what you mean. I asked about 93 files in > C:\_Restore\TEMP that were apparently created today. How/why did many > of those files get creation and modified dates earlier than today? You > said "This is the date of the original archived file." Of which > original archived file do you speak? > > Tom > > Mike M wrote: >> Don't be mislead by the file creation date. This is the date of the >> original archived file rather than when the file was archived. >
Guest MrTom Posted May 3, 2008 Posted May 3, 2008 Re: C:\_Restore\TEMP Aha! Thanks. I understand. I picked out a few of the files in C:\_Restore\TEMP with early (i.e. before today) modified dates, e.g. 2/12/08 or 3/1/08, and did a search for other files on my hard drive with the same modified dates. What I expected to see was some system file with the same modified date. No luck. No, I am not particularly concerned about the dates, just curious. Tom TomV wrote: > I think Mike's answer was clear. What does the system restore utility > do in Windows ME? "System Restore is designed to automatically monitor > and record changes made to the core Windows system files and to the > registry." The dates you're seeing are the dates of the original files > not the date(s) system restore created the archived files. Now where > did I read that before? > > MrTom wrote: >> I don't understand what you mean. I asked about 93 files in >> C:\_Restore\TEMP that were apparently created today. How/why did many >> of those files get creation and modified dates earlier than today? >> You said "This is the date of the original archived file." Of which >> original archived file do you speak? >> >> Tom >> >> Mike M wrote: >>> Don't be mislead by the file creation date. This is the date of the >>> original archived file rather than when the file was archived. >>
Guest Mike M Posted May 3, 2008 Posted May 3, 2008 Re: C:\_Restore\TEMP You still don't quite seem to understand what you have been told although I do understand the problem. The dates you are seeing are those of the original archived file. Now you say that searching your system you can't find a modified file with the same date. This is almost certainly because the file has changed, hence why a copy of the original is in the C:\_RESTORE\TEMP folder. Many of the files in the ..\TEMP folder will eventually be discarded when Win Me's state manager does its periodic analysis and archiving. Those files it considers to be necessary to restore when returning to an earlier checkpoint are then archived to FS????.CAB files in the C:\_RESTORE\ARCHIVE folder with the others being discarded. Each of the FS CAB files also contains what might be thought of a crib sheet, CHANGE.LOG which gives the original file name and location of each archived file. To complete the picture the RG*.CAB files are snapshots of the registry (and a few other system files such as system.ini and win.ini) captured at the time and date of each checkpoint. You can test this for example by deleting a file from your desktop that is of a type monitored by system restore. You should see the file then appear in the C:\_RESTORE\TEMP folder as an A?????.CPY file. There are some exceptions to what I've tried to explain but hopefully I've helped join a few more of the dots for you. -- Mike Maltby mike.maltby@gmail.com MrTom <NotMyAddress@invalid.net> wrote: > Aha! Thanks. I understand. > > I picked out a few of the files in C:\_Restore\TEMP with early (i.e. > before today) modified dates, e.g. 2/12/08 or 3/1/08, and did a search > for other files on my hard drive with the same modified dates. What I > expected to see was some system file with the same modified date. No > luck. > No, I am not particularly concerned about the dates, just curious.
Guest MrTom Posted May 5, 2008 Posted May 5, 2008 Re: C:\_Restore\TEMP You are correct, I still don't quite understand about the files in C:\_Restore. As you suggested I changed (you said delete) a file that system restore should be monitoring, and sure enough a new A*.CPY file popped up. But now I ask why? My understanding of system restore is that by using stored checkpoints (restore points) created either automatically or manually, system restore can roll back the system to its state (pretty nearly) at the time the checkpoint was taken. I don't see any reason for keeping a copy (A*.CPY) of files changed between checkpoints. A copy at the time the checkpoint is taken would seem to be sufficient. Right now I have two restore points saved. My C:\_RESTORE folder contains five folders (ARCHIVE, EXTRACT which is empty, LOGS, SFP which is empty, and TEMP which contains 195 A*CPY files). There are no FS*.CAB files. There are two RG*.CAB files, each of them containing 9 files (CLASSES.DAT, desktop.ini, powerpoint.ini, REGSNAPSHOT.LOG, SYSTEM.DAT, system.ini, USER.DAT, wavemix.ini, and win.ini). How do all the A*.CPY files in TEMP fit into the system restore process. Why, between checkpoints, are changed files being copied as A*.CPY files? Tom Mike M wrote: > You still don't quite seem to understand what you have been told > although I do understand the problem. The dates you are seeing are > those of the original archived file. Now you say that searching your > system you can't find a modified file with the same date. This is > almost certainly because the file has changed, hence why a copy of the > original is in the C:\_RESTORE\TEMP folder. Many of the files in the > ..\TEMP folder will eventually be discarded when Win Me's state manager > does its periodic analysis and archiving. Those files it considers to > be necessary to restore when returning to an earlier checkpoint are then > archived to FS????.CAB files in the C:\_RESTORE\ARCHIVE folder with the > others being discarded. Each of the FS CAB files also contains what > might be thought of a crib sheet, CHANGE.LOG which gives the original > file name and location of each archived file. To complete the picture > the RG*.CAB files are snapshots of the registry (and a few other system > files such as system.ini and win.ini) captured at the time and date of > each checkpoint. > > You can test this for example by deleting a file from your desktop that > is of a type monitored by system restore. You should see the file then > appear in the C:\_RESTORE\TEMP folder as an A?????.CPY file. There are > some exceptions to what I've tried to explain but hopefully I've helped > join a few more of the dots for you. MrTom <NotMyAddress@invalid.net> wrote: > Aha! Thanks. I understand. > > I picked out a few of the files in C:\_Restore\TEMP with early (i.e. > before today) modified dates, e.g. 2/12/08 or 3/1/08, and did a search > for other files on my hard drive with the same modified dates. What I > expected to see was some system file with the same modified date. No > luck. > No, I am not particularly concerned about the dates, just curious.
Guest Mike M Posted May 5, 2008 Posted May 5, 2008 Re: C:\_Restore\TEMP Tom, May I politely suggest you read what I have already posted in this thread and also give some thought as to what I have said is stored in a check point (RG*.CPY file) and what you think this might be. Think also about the total size of all of the files in your system and the size of those RG checkpoints. System Restore (SR), or rather Win Me's state manager, monitors changes made to the system. My reading of your post is that you appear to believe that systems restore is making an image of your system each time it makes a checkpoint. How many Gigabytes would that be and how big is the corresponding RG cab file? Even the best compression program couldn't store an image of your system in an RG file that is at most 20MB or so in size. Instead SR monitors CHANGES made to the system, that is files that have been either amended or deleted are archived and a note kept of those that are added. When you then use SR to a system to an earlier state it undoes those changes restoring copies of deleted or amended files from the archive and finally restores a copy of the registry from the RG cab file. > How do all the A*.CPY files in TEMP fit into the system restore > process. Why, between checkpoints, are changed files being copied > as A*.CPY files? I hate to have to say this but I have already answered this earlier in this thread which I suggest you might want to read again from the beginning. -- Mike Maltby mike.maltby@gmail.com MrTom <NotMyAddress@invalid.net> wrote: > You are correct, I still don't quite understand about the files in > C:\_Restore. As you suggested I changed (you said delete) a file that > system restore should be monitoring, and sure enough a new A*.CPY file > popped up. But now I ask why? > > My understanding of system restore is that by using stored checkpoints > (restore points) created either automatically or manually, system > restore can roll back the system to its state (pretty nearly) at the > time the checkpoint was taken. I don't see any reason for keeping a > copy (A*.CPY) of files changed between checkpoints. A copy at the > time the checkpoint is taken would seem to be sufficient. > > Right now I have two restore points saved. My C:\_RESTORE folder > contains five folders (ARCHIVE, EXTRACT which is empty, LOGS, SFP > which is empty, and TEMP which contains 195 A*CPY files). There are > no FS*.CAB files. There are two RG*.CAB files, each of them > containing 9 files (CLASSES.DAT, desktop.ini, powerpoint.ini, > REGSNAPSHOT.LOG, SYSTEM.DAT, system.ini, USER.DAT, wavemix.ini, and > win.ini). > How do all the A*.CPY files in TEMP fit into the system restore > process. Why, between checkpoints, are changed files being copied > as A*.CPY files?
Guest MrTom Posted May 5, 2008 Posted May 5, 2008 Re: C:\_Restore\TEMP Mike, Thanks, thanks, thanks. Finally, I do get it. I had been assuming that a snapshot of certain system files (more than in the RG*.CAB files) was taken at each checkpoint and these together with those in RG*.CAB were used to restore the system. I had no idea where this snapshot was, but as you finally got across to me CHANGES, not a snapshot, are saved. Tom Mike M wrote: > Tom, > > May I politely suggest you read what I have already posted in this > thread and also give some thought as to what I have said is stored in a > check point (RG*.CPY file) and what you think this might be. Think also > about the total size of all of the files in your system and the size of > those RG checkpoints. > > System Restore (SR), or rather Win Me's state manager, monitors changes > made to the system. My reading of your post is that you appear to > believe that systems restore is making an image of your system each time > it makes a checkpoint. How many Gigabytes would that be and how big is > the corresponding RG cab file? Even the best compression program > couldn't store an image of your system in an RG file that is at most > 20MB or so in size. Instead SR monitors CHANGES made to the system, > that is files that have been either amended or deleted are archived and > a note kept of those that are added. When you then use SR to a system > to an earlier state it undoes those changes restoring copies of deleted > or amended files from the archive and finally restores a copy of the > registry from the RG cab file. > >> How do all the A*.CPY files in TEMP fit into the system restore >> process. Why, between checkpoints, are changed files being copied >> as A*.CPY files? > > I hate to have to say this but I have already answered this earlier in > this thread which I suggest you might want to read again from the > beginning.
Guest Mike M Posted May 6, 2008 Posted May 6, 2008 Re: C:\_Restore\TEMP Tom, Yes you've got it! Sorry about the earlier lecture mode. System Restore isn't a back-up replacement but rather a mechanism allowing one to return to an earlier point in time by reversing changes made to the system. Not all files are monitored and none at all in certain areas. You can check the file extensions that are monitored by Win Me's state manager by having a look at the contents of the file FileList.xml which is located in Windows\System\Restore specifically the section headed <EXTENSIONS> <Include> about 2/3rds of the way down the file. You will see that most if not all common user data file types are _not_ monitored such as eml, dbx & pst (mail stores), txt, doc, wri, ppt, xls, (office), bmp, png, tif, (images), wav, mp3 (audio), avi, mpg (video), etc,etc. Areas that are NOT monitored regardless of file type include My Documents, Favourites, Cookies, Temporary Internet Files, etc. If you have any further questions please don't let my earlier replies put you off asking them or if you prefer feel free to e-mail me. -- Mike Maltby mike.maltby@gmail.com MrTom <NotMyAddress@invalid.net> wrote: > Mike, > > Thanks, thanks, thanks. Finally, I do get it. I had been assuming > that a snapshot of certain system files (more than in the RG*.CAB > files) was taken at each checkpoint and these together with those in > RG*.CAB were used to restore the system. I had no idea where this > snapshot was, but as you finally got across to me CHANGES, not a > snapshot, are saved. > Tom > > Mike M wrote: >> Tom, >> >> May I politely suggest you read what I have already posted in this >> thread and also give some thought as to what I have said is stored >> in a check point (RG*.CPY file) and what you think this might be. Think >> also about the total size of all of the files in your system >> and the size of those RG checkpoints. >> >> System Restore (SR), or rather Win Me's state manager, monitors >> changes made to the system. My reading of your post is that you >> appear to believe that systems restore is making an image of your >> system each time it makes a checkpoint. How many Gigabytes would >> that be and how big is the corresponding RG cab file? Even the best >> compression program couldn't store an image of your system in an RG >> file that is at most 20MB or so in size. Instead SR monitors >> CHANGES made to the system, that is files that have been either >> amended or deleted are archived and a note kept of those that are >> added. When you then use SR to a system to an earlier state it >> undoes those changes restoring copies of deleted or amended files >> from the archive and finally restores a copy of the registry from >> the RG cab file. >>> How do all the A*.CPY files in TEMP fit into the system restore >>> process. Why, between checkpoints, are changed files being copied >>> as A*.CPY files? >> >> I hate to have to say this but I have already answered this earlier >> in this thread which I suggest you might want to read again from the >> beginning.
Recommended Posts