Additional cleaning areas?

CCleaner for Windows CCleaner Windows Suggestions
1

While reading some discussions going on in other threads, I discovered there are areas of the system that CCleaner doesn't touch. This program -- http://www.nirsoft.net/utils/computer_activity_view.html -- seems to show some system activity that isn't cleaned or wiped. But, this program -- http://www.r-wipe.com/ --, I understand, does.

While I realize CCleaner isn't forensic grade (nor is that important to me), I think it would important, if not vital, to add these items in. If this information is so easily accessible via a freeware tool, why not make it erasable?

(mods - if you consider this a duplicate thread of another topic, just zap it)

2

Hi

I think C Cleaner cleans especially the part that we can see in the hard drive. There are many superhidden or hidden files it doesn't touch: pagefile.sys, hiberfile.sys, $MFT, $UsnJrnl: $J, $Bitmap, $MFTMirr, $Secure$SDS, $AttribDef, $Boot, $UpCase, $LogFile, $Secure:$SH, $Secure:$S and ...

After years, they take up much space. But we do not see. Cleaning has mostly a psychological effect.

I found a solution, I formatted FAT32 and I disable everything I can. There is none of these.

Best Regards

R G

3

Interesting new tool there from Nirsoft. It shows an absolute ton of install dates on the system, don't know if removing said info would cause an issue though in for instance Add/Remove Programs, etc.

4

Yes it would. Some folks (myself included) like to have some logged information available for system maintenance. Some people don't. On one of my personal systems, I unchecked a lot of "clear XYZ logs" boxes.

So if the software engineers make CCleaner dig further into the system. And I believe they should. This could be a non-default option. You manually check it, and get a popup warning before proceeding.

5

Hi

I think C Cleaner cleans especially the part that we can see in the hard drive. There are many superhidden or hidden files it doesn't touch: pagefile.sys, hiberfile.sys, $MFT, $UsnJrnl: $J, $Bitmap, $MFTMirr, $Secure$SDS, $AttribDef, $Boot, $UpCase, $LogFile, $Secure:$SH, $Secure:$S and ...

After years, they take up much space. But we do not see. Cleaning has mostly a psychological effect.

I found a solution, I formatted FAT32 and I disable everything I can. There is none of these.

Best Regards

R G

Ohh my! Heavens to Betsy! You do live dangerously. So many a-time has the roubustness & redundancy of NTFS (and its menagerie of metafiles) saved my ass.

I've not experienced mega-growth on any metafile, to date, on a 10-year, installed-once, XP home system. Including the $user journal. While it may seem to take gigs upon gigs in some systems. That's not really the case. It's rolling counter, the file is I'm currently at a 2GB pagefile, 2GB hiberfile, and I locked the $MFT at 750MB including reserve. I do have a lot of tiny 2k files which fit nicely there. And the rest of the NTFS entourage comes in around 50-100MB. Just as I had planned it out years ago. The system is used daily. And all up to date as far as software goes.

I believe (psychologically or not) that cleaning lightens the load, especially on on older marginal systems. And it allows you to prep the disk prior to consolidation of free space. A clean system has less disk thrashing, especially if you do a file placement order operation. Putting the important data all on the outside rim and all close together.

But this is way beyond the scope of the original posting I made and I do not want to discuss cleaning and optimization any further unless it is related to my original posting. Why not start another thread about optimzing and spiffing up the metafiles. eh?

6

Whooops! my bad I keep calling the Update Sequence Number Journal the UserJournal. I've never gotten over that one.

7

Ohh my! Heavens to Betsy! You do live dangerously. So many a-time has the roubustness & redundancy of NTFS (and its menagerie of metafiles) saved my ass.

I tend to agree.

I have only had a single instance of a major disaster when I appreciated in practice the vast superiority of NTFS over FAT32,

but my ultimate full recovery was down to using Partition Image backups.

Anyone who does not have up to date partition image backups really ought to use NTFS if they need any files to survive the next shut-down and restart

My Laptop had 7 partitions.

C;\ and three others were NTFS because that was the default for XP.

The other three were FAT32 for very good reasons :-

The Acronis Secure Zone Hidden partition has created by Acronis as FAT32.

After using Win95 I was so ticked off by XP restrictions I chose avoidance by creating a FAT32 partition for my "Portable Applications".

Restoring an Acronis partition image backup via its Linux Boot CD took 3 times as long from an NTFS archive as it did when held in a FAT32 partition,

so both the external drive which held all backups, and an internal partition for a few duplicate backups, were all FAT32.

(I deduce that FAT32 and Linux are on good terms, but NTFS gets Linux tied up in knots.)

I tried to create an extra internal partition, but disaster struck and Windows was no more.

MiniTool Partition Wizard Boot Recovery CD found that all partitions had totally vanished.

Minitool included a Partition Recovery Wizard which had a problem with the Acronis Hidden partition which I rarely used so I did not retry.

The other 6 partitions were all recovered.

Windows Booted up and told me that H:\ (my Portable Apps FAT32) needed repair and I had to run chkdsk.

Chkdsk found and fixed tons of errors and things, after which everything seemed to work well.

Upon rebooting no further problems were reported until I chose to run chkdsk on all the other partitions,

and that found nothing significantly wrong with any of the four NTFS partitions,

and a massive amount of nasties with the FAT32 that held duplicate backups.

Then I restored image backups of all the important partitions.

I suffered a minor panic when the disaster struck,

but took the opportunity to confirm that I had two independent techniques for recovery.

So much happier to say "been there and survived" rather than "I have filed in the basement a recovery plan by a committee" :D

Secondary conclusion :-

I do not know how it does it, but NTFS is much safer than FAT32,

8

There are many superhidden or hidden files it doesn't touch: pagefile.sys, hiberfile.sys, $MFT, $UsnJrnl: $J, $Bitmap, $MFTMirr, $Secure$SDS, $AttribDef, $Boot, $UpCase, $LogFile, $Secure:$SH, $Secure:$S and ...

I found a solution, I formatted FAT32 and I disable everything I can. There is none of these.

What about UDF?

I use UDF format for my flash drives, because XP can read from it, but not write to it. Thus, all XP autorun viruses are stopped cold.

You can format drives into UDF (Universal Disk Format) from the commandline in Windows 7.

9

Hi, Keatah and Alan B,

I don't think I live dangerously,

I have a 150 GB hard drive, 5 partitions in FAT 32.

XP on C: and XP on G:

The Boot.ini is:

[boot loader]

timeout = 3

default = multi (0) disk (0) rdisk (0) partition (5) \ WINDOWS

[operating systems]

multi (0) disk (0) rdisk (0) partition (1) \ WINDOWS = "XP C" / noexecute = optin / fastdetect

multi (0) disk (0) rdisk (0) partition (5) \ WINDOWS = "XP G" / noexecute = optin / fastdetect

If I have a problem on XP G: I started with XP C: I deleted the contents of G: except that I want to keep. And I make a copy and paste Documents and Settings, Intel, Program Files and WINDOWS I saved after formatting and reinstalling XP.

I recorded four folders, taking care to disable the Recycle Bin, restore, indexing files and hibernation.

As C:, D:, ... are FAT32, I can open the System Volume Information containing the index and restore points.

They are empty.

Best regards

R G

10

Some of the inherent safety of NTFS comes from it being a journaling file system. Changes are made to a file, and written. But the changes are not accepted till validated. If the disk write operation you requested doesn't make it past the validation stage, the old version of the file remains active.

It's like trading in a car. You keep your old one till the car company builds you a new one and the transfer papers are signed. If any thing goes wrong up to and including the final signature, you still have your old car to fall back on. (as long as it doesn't fall apart!)

11

http://en.wikipedia.org/wiki/Journaling_file_system

12

I do not know how it does it, but NTFS is much safer than FAT32,

Yeah, I wouldn't bother with FAT32 for any OS install these days. It's a completely different story though for having to use FAT32 with things like USB Thumb Drives for compatibility with other hardware that has zero support for NTFS.

13

Agreed. NTFS is far superior than FAT in many areas, not only reliability and robustness.

14

I learnt about Unix journalling before there was XP and NTFS,

and I always thought of Windows NTFS as being a pale imitation of the real thing.

Until looking at the above link today,

I understood that the "beauty" of NTFS was the capability of a file update "roll-back" to the pre-update state upon any failure before the final "commit",

and this would allow a retry.

Once the update was committed I thought the journal was no longer relevant,

and a system crash / head crash / etc would damage files in an NTFS partition just as badly as files in a FAT32 partition.

Hence my surprise to find that all the NTFS files survived perfectly whilst FAT32 suffered upon a total partition loss / recovery sequence.

I read in the quoted link

a journaled file system allocates a special area—the journal—in which it records the changes it will make ahead of time. After a crash, recovery simply involves reading the journal from the file system and replaying changes from this journal until the file system is consistent again. The changes are thus said to be atomic (not divisible) in that they either:
  • succeed (succeeded originally or are replayed completely during recovery), or
  • are not replayed at all (are skipped because they had not yet been completely written to the journal before the crash occurred).

That I already understood.

Further on I read

The internal format of the journal must guard against crashes while the journal itself is being written to. Many journal implementations (such as the JBD2 layer in ext4) bracket every change logged with a checksum, on the understanding that a crash would leave a partially written change with a missing (or mismatched) checksum that can simply be ignored when replaying the journal at next remount.

QUESTIONS :-

Does the "next remount" correspond to the "next reboot" ?

Can the journal information persist for a long period of time,

and when my partitions suffered grief then at the lowest of levels the NTFS and FAT32 files may have suffered similar damage,

but when Windows next booted it was able to "instantly" use the journals to restore consistency (and hopefully correctness) to the NTFS files before telling me I had to run CHKDSK on the non-journalled FAT32 ?

BIG QUESTION :-

If CCleaner purges all the "Additional Cleaning Areas" such as are found by (but not limited to) http://www.nirsoft.n...ivity_view.html

would it be damaging the journalling system and making NTFS and FAT32 equally vulnerable to a system crash ?

15

Hence my surprise to find that all the NTFS files survived perfectly whilst FAT32 suffered upon a total partition loss / recovery sequence.

From my recent troubles with 7-Zip v9.20 causing my system to crash in a way that sounded like the hard disks were being disengaged (best description I can think of) if I had been using FAT32 I would've probably lost a whopping amount of files on my backup and files only hard disks/partitions. I have since went back to 7-Zip v4.65 from many years ago and the issues are completely resolved. I have to think that NTFS kept my files intact without any corruption, since chkdsk found very little to fix after the crashing.

16

EXT4 file system for all your Windows needs.

Wait..