Jump to content

Augeas

Moderators
  • Posts

    4,542
  • Joined

Posts posted by Augeas

  1. If you mean that the file state shows as recoverable, then don't read too much into it. Sometimes the file is marked as recoverable (as Piriform says) and contains rubbish. The test is whether what you recover is actually the original file.

     

    Deleted files can also be overwritten with a valid live file. In this case the deleted file will show the contents of the live file, and if it's recovered the live file will be 'recovered'. This is a quite valid operation.

  2. I think we can safely put money on the 22 gb being a false reading. It would be quite a feat to accumulate 22 gb of temp files, a third of the total data.

     

    NTFS cluster size default is 4k for both XP and Vista, I believe.

     

    Another complication is how disk space and data size is calculated. Is disk space the numbers of sectors times 512? And whilst a file may be reported as a certain size, when it is written to disk the data is coded and expanded by a significant amout (I've read figures of 6 to 13%). So 512 bytes of user data will not fit into 512 bytes of disk space. I think that CC reports the user data size of the files to be deleted, not the actual increased space they occupy on the disk.

  3. No miracle fixes, unfortunately. If you have found the files using a normal scan then perhaps the files have been overwritten and that's what you have recovered (you can see this, and what's in the header, in the Recuva run).

     

    This question has been raised several times before in the forum so a search might be of help. I can't remember what resolution, if any, there was.

  4. On the first run CC said it would remove 22 gb of data?

     

    I think that there's so much going on in Windows that it's impossible to do an accurate before and after count. For instance I've just run properties on the C drive, opened and closed CC, and run properties again. I now have 65k less free space. That's not a lot, but opening and closing CC isn't much either. What's used 65k, and will CC clean it later?

     

    Slack space is a good theory, I wish I'd thought of that. There's always the index.dat files, which are only deleted at boot time. I can't remember if they are included in the space removed figure. Well, to be honest I've never bothered about it before.

  5. One would, or might, think that disabling prefetch and thus not having the boot trace file available would slow boot time, but I have no data on this. I assume the point of the boot trace file is to speed up boot time. (It's NTOSBOOT-B00DFAAD.pf, not Layout.ini, that is the boot trace file, Layout.ini is used to defrag prefetch files.)

     

    I really couldn't say why Vista does anything. I guess M/S thinks it's better that way.

     

    If you used CC to clean the prefetch folder then it wouldn't touch either the boot trace file or Layout.ini, as it only cleans old and invalid entries, according to the documentation. So boot time would be unaffected.

  6. Try the date modified time on ccleaner.exe in prefetch folder. That seems to update when cc is launched.

     

    Alternatively (and probably easier) I've found that is you set the Last Accessed Date to be shown in your folder view, and then open program files/ccleaner, that should show the last launched/accessed date alongside ccleaner.exe. Using Properties to show the last accessed date just shows the current time, as running Properties seems to be counted as an access.

  7. I'm pleased you have made some progress. As far as I know this 'empty recycler' problem has been found by a few people, and I don't think there's a solution to it yet. I don't even know if the developers can reproduce the problem: it's really up to them now.

  8. Have a look at http://forum.piriform.com/lofiversion/index.php/t20001.html http://forum.piriform.com/lofiversion/index.php/t6021.html and http://forums.cnet.com/5208-6121_102-0.html?threadID=171585 for a start.

     

    There are so many variables here that you will just have to plug away at them. Enough partition space, running any disk wipe stuff, other a/v, firewall s/w, any Norton stuff, any malware, etc. I have no definitive answer.

  9. Plan B, Google. "No restore points" xp turns up 18,000 hits, and a quick look shows stuff like 'try disabling it, restart, then enable it, that usually does the trick,' and this 'The problem with System Restore is that it's a miserably designed application, one that could only be produced by a company with no competition in the marketplace. You need to periodically check up on it because it both breaks and turns itself off and in neither case does Windows XP tell you that anything is wrong.'

     

    After that this entry from M/S http://support.microsoft.com/default.aspx?...kb;en-us;302796 brings up the usual check list. There are other reasons, mostly conflict with other software. If the turn sys restore off/on doesn't work then I can only suggest a Google trawl.

     

    PS Edited this to be more relevant.

  10. There's no option to check or uncheck for deleting sys restore points, CC doesn't do this (well, not intentionally).

     

    Are you using CC to look at the restore points you created? Do you see them when you create them?

     

    Can you see any restore points when you look at them using System Restore?

     

    When using CC to look at restore points, have all the restore points gone or do you see the latest?

  11. The prefetch folder does not (I believe) cause any program components to be loaded into memory, but builds a trace file for commonly used applications. When the application is called by the user the prefetch folder is searched and if a relevant trace file is found it is used to prefetch the relevant components in one go before the application is allowed to launch.

     

    There is a trace file in the prefetch folder for the boot process, so disabling prefetching should slow boot time, not speed it up.

     

    As the prefetch folder contains no executable data it should not be a significant malware hiding place.

     

    What was unknown to me is that there is a file named Layout.ini in the prefetch folder that holds a list of files and directories in the order that they are referenced during boot or application start. Every three days or so, during system idle periods, the Task Scheduler updates Layout.ini and then launches the sys defragger with a command-line option that only defrags the files pointed to by Layout.ini. Defragger finds a contiguous area on each volume large enough to hold all the listed files and directories and moves them in their entirety into that area. Future prefetch operations will even be faster as all the data to be read is stored physically on the disk one after the other in the order it will be read.

     

    Now who would want to deny Windows that clever trick?

  12. I assume they are the MFT entries (File Record Segments, as M/S calls them) that Eraser has overwritten and deleted. There does seem to be rather a lot, perhaps that's to do with the way that Eraser fills the disk to ensure that all old data is overwritten. But, as you say, the old filenames are gone.

     

    Still nobody who uses CC's wipe free space has posted what shows in a Recuva normal scan (the MFT) after wiping.....

  13. I know of no way to recover the list. Yes, it would be handy to right click and save the list to a text file, as with CC. I don't know how relevant a saved list would be to recoveries, as the list doesn't show any sector info giving the location of the file, so you would probably have to scan again to find it. In any event the list is always changing as the pc is used, so it would quickly become obsolete.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.