Jump to content
Piriform Community Forums

Augeas

Moderators
  • Content count

    3,881
  • Joined

  • Last visited

Community Reputation

0 Neutral

1 Follower

About Augeas

  • Rank
    Moderator

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Gender
    Not Telling
  • Location
    Where Stuff is made, UK

Recent Profile Visitors

1,047 profile views
  1. That's enough squabbling, thanks.
  2. No, try it yourself, in Advanced mode if necessary. Read the bit about dates.
  3. 96 GB RAM not enough??

    That's me trying to be too clever. When Recuva scans it holds all its info in memory as it doesn't write to the disk, for obvious reasons. When it runs a recovery I can't see a reason why much more is held in memory - a recovery log I suppose, which can be quite large with 48 million files to be recovered. But your original post says that you're running out of ram, and your second post says you're running out of disk space. Post two also says on the bottom line that 48 million files are being recovered after the pic filter has been applied. You are biting off a great deal, perhaps more than Recuva can chew.
  4. 96 GB RAM not enough??

    It doesn't matter what the original folder size was, you are finding, and attempting to recover, all deleted pic files. Recuva has found 48 million pic files, even at 1 cluster each that's nearly 200 gb. At ten clusters each, say, that's 2 tb to recover. By the way I have no idea what Recuva writes to memory, apart from everything.
  5. Recovery succesful, 0 files recovered

    There are a lot of similar cases in the forum and my poor fingers, not to mention my remaining brain cells, shy away from typing the same old stuff again. But, even though goats can be a pain in the backside, here's a brief synopsis: How did you select your files for recovery? Did you have a filter on file name or path? If you did, or the files were zero size, or were system files, or were secureley deleted, Recuva may well have not recovered any successfully. Didn't you get an error message saying why? I'm sure a screen shot (no, not of the goat), would help.
  6. Wipe Free space not working?

    Everything's a partition in Windows, so don't worrry about that. The pic in post 1 shows entries in the MFT after they have been wiped, that is after enough 712-byte files have been allocated to overwrite all the free records in the MFT, and then deleted. Drive Wiper runs a wipe MFT before the wipe free space, so you should have seen a Wiping MFT message first. It's very likely that there will be some 'deleted' records in the MFT, whether ZZ's or other names. That's what you see with a normal scan (and also with a deep scan, as a normal scan is run first). If you don't see any results with a normal scan, then: 1) So many new files have been allocated that the MFT is full and is now creating new records for new file allocations, i.e. there are no deleted records in the MFT. 2) There is something in the file/path filter box in Recuva, and nothing corresponding to this filter is found. 3) The option in Recuva to show securely deleted files is unchecked, and somehow Recuva can identify those ZZ files as securely deleted (maybe a specific file header?). The screenshot in post 4 is confusing, as file and folder names are only held in the MFT, unless Recuva is digging them up from somewhere I am unaware of. I have found a problem with WFS, in that in a drive that has a lot of fragmented free space (although the live files themselves may not be fragmented) some of the smaller space allocations are missed. This might be your case as the file sizes are relatively small. To get rid of them use Recuva's overwrite. This won't get rid ofthe file names, but as I don't know where they're coming from I can't really suggest anything else.
  7. Wipe Free space not working?

    Are you using Drive Wiper or Wipe Free Space from Options/Settings? And what version of CC?
  8. I suppose it is possible for a random set of characters to mimic an flv header, but four times is a bit of a coincidence. You can of course try whatever software you choose, but I think you need professional help, or at least someone knowledgeable who can look at your disk in greater depth than we have here.
  9. In a deep scan Recuva looks for a known file header, and determines the file type from that. It must have found four flv file headers. I've no idea how it determines the file size, possibly reads the following clusters until another known file header is found. Or they might just be big flv files. Why not play them to see what they contain, but don't blame me if you get sacked. There's no way to 'convert' these, they are flv headers. I don't think you'll get any further with Recuva.
  10. Wipe free space on SSD and HDD

    Yes, it has been discussed endlessly, mostly by people whose knowledge is, or was, HDD based (and I'm one of those too). We can more or less figure out what happens on a hdd when a wfs is run, but who knows what an SSD controller is doing? As I'm sure you know, a TRIM (or a defrag Optimize) won't get rid of file or folder names and paths, because these are held in the MFT, which will never be trimmed. A wfs using Drive Wiper runs a wipe MFT first, and overwrites the deleted records in the MFT by allocating enough small files to fill all the unused records. This is a ham-fisted way of wiping the MFT as it involves two separate page writes (allocate and deallocate) to the MFT bitmap block, two to the offending MFT file record, and at least two to the owning folder. So a wipe MFT could write thousands of SSD pages, but there is no other method that I or Piriform know of to get rid of those file names. It's a pity that the wipe MFT function is not available separately, as a wfs must be the complete pig-fisted way of wiping the MFT. The actual wipe free space process is superflous to wiping the MFT and a defrag Optimize will do the wfs part far more efficiently than CC's wfs. There's no real answer to your problem, except mine which is to ignore the file names and stop worrying. Who is going to run Recuva on your device to see what files you have deleted? There are so many other things to be paraniod about.
  11. Unrecoverable?

    Unrecoverable means that all (or virtually all, I don't know the actual figure) of the file's clusters have been overwritten. Recuva will recover whatever is in those clusters. The recovered file will contain whatever overwrote it, and will be of no use in reconstructing the original deleted file. In advanced mode you can see what clusters have been overwritten, and by what, in the Info pane.
  12. Excellent means that no clusters have been overwritten. The contents of the clusters could be anything, Recuva does not make any judgement on the veracity of the data. What has been recovered is what is on the disk, no more or less. I'm not going to open an unknown excel file, and not everyone has Office, so please post screen shots only.
  13. You can, in Advanced mode, put part or all of the folder name in the File or Path box, and all files identified with that folder will be shown, and can be selected.
  14. It's there in Analyse, but not in run, presumably because there would be little point in it after the file has been deleted. I haven't checked if this is the same on older versions.
  15. Portable 32 bit exec v540 7,817 kb, v541 12,464 kb, 59.5% increase.
×