Augeas
-
Posts
4,542 -
Joined
Posts posted by Augeas
-
-
Now this is puzzling me.
I'm running XPHSP3 with IE8, one user as admin. I'm having a terrible job getting rid of some temp internet files in IE8 (which I rarely use).
CC lists these files and says it cleans them from C:\Documents and Settings\Me\Local Settings\Temporary Internet Files, and when I run CC and then look at that folder it shows as empty. Yet when I go to IE8 Tools/Options/Browsing History/Settings/Show Files, all the files are still there. Where are the little devils hiding, and how can I splat them with CC?
You may have to close the folder view to get this effect, and I have a blank home page on my pc, so there's no fresh page loading taking place.
Oh I give up. Somehow I have managed (I think) to remove them with CC. I analysed Temp Int F, it showed 12 files to be deleted. I cleaned and it cleaned 114. They seem to have gone.
The peculiar thing was that when I ran CC before and they didn't go, they all had a last modified date/time of the CC runtime. So CC was doing something but they just wouldn't go. I wonder if I had some sort of lock on the folder as I either had it opened or I was lurking in the folder structure.
It is a slight problem. I'll try to reproduce it when I am bored later.
-
As it says in the docs, either the file is under 1k and resides in the MFT, or is zero length, or has already been overwritten by another file.
-
Did you select All Drives in Recuva's drive list instead of just selecting the camera card? Did you then tick the select all tickbox alongside the Filename? Did you not notice that the vast number of files had strange names and were not pics? Do you not remember where you asked the recovered files to be stored? Did you then decide that deleting programs was preferable to deleting unwanted data?
Right-click on the Recycler icon and select Empty Recycle Bin. That'll be a start.
If you recovered the files to a new or empty folder then go to it and shift/del to delete it. If you can't remember the folder name then look at or search for the create date being the time you ran Recuva. If you recovered to a shared folder then find it and go through the unwanted entries with shift/del.
This is such a catalogue of compound errors I don't know if you are taking the mickey: if you are then I don't really mind.
-
I'm not quite sure what you're saying. That CC doesn't wipe the last 49 mb? That 49 mb is all the free space you have? That CC never gets past 99%?
Wipe Free Space will always wipe all your free space every time you use it, even if you run it every day. (I would think that running it every few months would be more than enough.) You could try unticking the Wipe MFT Free Space box and see what that does.
-
Just reboot and they will be cleaned. CC can't access these files when Windows is running, so they are deleted and recreated at pc boot time.
-
Well Don, I wouldn't dream of suggesting that you've spent an evening of festive imbibing, but I am intrigued by the philosphical concept of overwriting nothing. It may be that you mean overwriting the file names in the MFT, which is possible with CCleaner and, I believe, Eraser, but that would be altogether too sensible and boring an answer.
-
And the same to you Deke, alcohol has started to flow here...
I've identified my 22 securely deleted files as those with no filename, path as c:\?\ and zero length. I don't know where they came from, presumably from the sys restore file dump. My ZZZZ.ZZ file still counts as a securely deleted file as well. I think I need more alcohol.
-
Another spanner in the works. Previously if I ticked or unticked Show Securely Deleted Files there was no difference to the number of files displayed (i.e there were no files recognised as securely deleted). This afternoon sys restore dumped a few hundred deleted files as it does every week or so. Now if I untick Show Securely Deleted Files there are 22 files hidden, and if I tick it all are shown. None of the files are of the familiar zz format. Fifty-eight have z in the name, four have zz, and only two have zzz (or more) in the filename. So zz isn't the way of identifying a securely deleted file. Surely Piriform works in mysterious ways.
-
I don't actually use wfs, only on flash drives to test it, and they're FAT. Sometimes an interrupted wfs leaves large files in the c dir, these can be safely deleted (and can be seen using Recuva, if you haven't wiped the MFT!).
I wonder what method CC uses to overwrite the MFT entries. The usual way is to fill up the drive with large files (as wfs does) then allocate new small files under 1k to fill up the MFT, then delete the lot. Maybe that's the only way for a Windows application. But if you did that then there would be at least one entry in the MFT that would represent a very large file.
I guess you could obtain the number of free entries in the MFT and then allocate the same number (or a few more to be sure) of small files. In that way you could do a MFT wipe without wiping all the free space. Nobody appears to do that though. Well, you can do that on a DIY basis if you want. It would be a good tweak for CC, as many users want to wipe the MFT without the pain of wiping free space.
-
More tests. I copied a 15k file into my crap folder and secureley deleted it. It showed in Recuva, I set the option not to show securely deleted files, and it didn't show.
I then copied the same file into my crap folder, and renamed it to ZZZZZZ.ZZZ and ran CC on Normal Deletion. I scanned with Recuva and the file showed with the option ticked, and disappeared with the option unticked. So it appears that the filename is the selection criterion for secure deletion. It also shows that if some fool names his files ZZZZZZ.ZZZ they will be classed as securely deleted, even though they aren't. (My jpeg file was fully visible in the preview panel.)
-
Hi Deke,
I asked these questions as I was trying to determine what CC does to remove entries from the MFT. It appears that it overwrites them with some form of ZZ file name: whilst it would be better if no other secure deletion takes place so that there's no confusion with the ZZ filenames of that process there's still some info here.
I wonder in what order the various processes take place? (I've just thought of this.) If you run secure delete and wfs in one run of CC, does it secure delete the files (renaming them to ZZ), then wipe free space and clear the MFT, including overwriting the entries in the MFT just overwritten in the secure delete process? So that the secure deleted files would not be seen separately in the MFT? That might explain why your files are all 600 bytes long. Ha!
Now how does Recuva know that a file has been securely deleted? I must admit I hadn't seen that option. Does this apply to all CC's secureley deleted files or just those that have had an MFT wipe? The option makes no difference on my pc. I don't think there are any flags in the file header that say securely deleted, so filename is just about all there is to go on. The ZZ format is variable, or appears to be. Can you confirm that Deke? So does Recuva look for files held in the MFT (i.e less than 1k) and contents binary zero? Or some other method?
-
Ah, somebody brave enough to run wfs. For the curious, can you clarify a few points?
Did you run wipe free space only, or did you also delete any files?
If you deleted files, did you use secure deletion?
Are all the files Recuva finds renamed to ZZetc, or just some?
Your thumbnail of the Recuva overwrite shows two files overwritten. It is normal for small files in the MFT (less than 1k) not to be overwritten by Recuva, I guess you found two files in the batch you tested that were greater than 1k and thus were overwritten?
I assume that the files that Recuva found are of varying sizes, non?
Is the Date Last Modified of all the files the same (i.e. when you ran CC), or varying?
-
Normal deletion is indeed the same as a shift/del in Windows, and the chosen setting applies to the files deleted when Run Cleaner is pressed.
-
-1
You would have to restrict such an option to say Custom Files only. I can't see the point of saving many thousands of temp files to the recycler, and repeating that each time CC is run. The default would have to be on, or else there would be posters saying 'I need a file and it's been deleted with the standard settings!' With it on, of course, they would say 'I ran CC and didn't gain any space!' It would cause confusion with secure file deletion. It would mislead those who thought they were deleting sensitive files. If your pc played up you wouldn't know which file to reinstate anyway.
I've never been bothered with the stuff that CC deletes. It doesn't delete any vital files unless the user is, shall we say, wayward.
-
'The "Wipe Free Space" option fills up all of the "empty" space on your hard drive with random data.'
CC uses one pass of zeroes. As far as I know.
'Does using the 'Wipe Free Space' option actually overwrite the empty disk space 7 times?'
No. The Secure Delete option applies to files and folders. The Wipe Free Space option invokes wfs, and does not use whatever option is chosen for securely deleting files. As far as I know.
'Data that has been overwritten can be recovered?'
There is no evidence that this can be done, or has ever been done, in any practical way. The idea was mooted in the 1990's on Winchester disks.
'Utilities such as CCleaner's 'Wipe Free Space' are not going to touch this (bad) sector.'
I don't believe that CC accesses bad sectors.
'Should we worry about this?'
That's up to you, but I don't.
-
Come on Richie, what happened?
-
It worked when I tested it, with or without a file extension.
-
WHY ?
in Defraggler
From the Piriform Defraggler docs the implication is that the purple blocks denote the MFT reserved space (the MFT Zone). In XP this is set at installation time to a default of 12.5% of the total disk size. This zone has always been on your disk, although I can't say whether prior versions of Defraggler have reported and shown it as such.
The MFT zone, and the $mft files inside it, are the way that the file system (NTFS) works. You can alter the size of the zone (only upwards, I believe) but you can't get rid of it. I don't know why this hasn't been visible to you before, but you can bet your bottom dollar that it's always been there.
Stretching theories a little, it might be the case that if the disk were packed full of data then data would be forced into the MFT Zone, and Defraggler might report it differently, but I wouldn't put anyone's dollar on that.
-
The pc belongs to the hostel? You downloaded pics from your camera to the pc and then deleted the pics from the camera? How were you expecting to get the pics home?
As JDP says, if the pics were downloaded to a folder which was not a Windows temporary folder or Temp Internet files etc then CC would not under normal settings delete them. (Actually I added quite a bit to what JDP said.) Are you sure they have gone - do a search on date or filename etc. Are you sure that the download worked - did you see the pics on the pc after you'd downloaded them?
On further reading the pc could be yours, if so ignore much of the first para. Mind you a flash drive or a few CDR's would help.
If you can't find the pics you could run recuva on the camera memory card, or at least have a go. If you find them there then save them to a properly named folder on the pc, check that they're there, copy/back them up to some other media.
-
How long did you wait? One tb is, or can be (depending on prior use of the disk) a huge amount of data to run a deep scan against. Vaguely extrapolating my puny amount of data which takes over an hour to deep scan, you could be looking at anything up to 48 hrs or so.
-
What means do I have to force 5 million entries in MFT, without having to create a file for each entry?
None that I know of, but I have never even contemplated creating an MFT of that size.
Is there a way to make (the MFT) grow in 1 block without fragmentation?I guess that's in excess of 5 gb. In XP the MFT should be contiguous within the MFT zone, as long as the zone is large enough in the first place and the disk never becomes full enough to force data into the MFT zone. In Vista I believe (from memory) that the MFT is allocated in 200 mb chunks which can go anywhere. M/S says that this is no great problem, but no doubt there are ways of making them contiguous if you wish. There's some M/S info on the Vista MFT which should be easy to find on Google. I have however no experience on a system of your size.
P.S. Further to Recuva always doing a full scan, it doesn't appear to scan for undeleted files unless you ask it to. I doubt if this is much help though.
-
As it says in your link, this topic has been discussed many times before.
As you've used Diskeeper (with which I am not familiar) to reserve MFT records you've accepted that the MFT doesn't shrink in size as files are deleted, otherwise there would be no point it running it. That's point one.
Point two is that you can't 'delete' any file name in the MFT, or erase it, or wipe it. File names (anything on the disk in fact) can only be overwritten. I understand that NTFS will clear out the entire file name field (no no no, not clear out, overwrite - possibly with zeroes) before writing the new filename, so no trace of the old name exists.
Presumably Diskeeper uses some harmless file name to create those entries, so what advantage would it be to 'delete' them? You would only be replacing one set of invented names with another. I don't know what length files Diskeeper creates: you could I suppose replace them with zero length files if they're not already, but that would be a lot of effort for very little reward.
If you're thinking of reducing Recuva's time to scan, or getting it to scan at all, then you're probably going to be disappointed. In my use of Recuva it has always done a full scan before showing the results, so if the Show Zero Length Files option is unticked it makes no difference to the scan, just filters the results shown.
Your final question is really invalid as it can't be done, removal that is. You'll just have to live with 5m file names.
-
Hmm. It worked when I tested it, with or without a file extension. The actual entry I used to test was C:\Documents and Settings\Me\My Documents\New Folder\xxx*.*
It worked with varying file names beginning with xxx
-
Yes, this would be a good idea. I don't ever remember it being implemented in any release. As there are no date or size columns in thumbnail view perhaps just to maintain the sort order from the list view would be a reasonable compromise?
Unable to overwrite files using recuva.
in Recuva
Posted
Are you having trouble overwriting everything you attempt to secure delete, or some you can and some you can't? Make sure that what you're seeing isn't the contents of another file that has overwritten the file you're deleting. (I'm sure there's a less complicated way of saying that.) For instance if you have live pic files they may well be written to the same space that the deleted file used to occupy, and when you follow the deleted file pointer you see the live file. Alternatively if a file of any sort has been completely overwritten by another file then Recuva will show the Not Overwritten message. In both cases this is normal. That's about the extent of my guesswork. I don't think you have to be in admin mode to run Recuva, but you could check that too.