Shodan816

Been testing it on Vista for a couple of days now with no problems whatsoever. THANKS ! ! !

Window sizes are 'lookin' good !' THANKS ! ! !

At least under Vista (and surely XP, as well), Recuva is not storing the horizontal window size correctly, at least for numbers over 999. Think I have finally figured out what is happening. Through trial and error, I set the following value in my INI file to various horizontal widths: window_width=999 It turns out that Recuva will accept any value up to 999, but not 1000 or above (e.g., a 4 digit value.) As soon as I change the value to 1000 or more, Recuva resets the horizontal window width back to it's default of 626. Hope this helps to narrow down the bug. ;-) Thanks for listening.

Not that we're taking a vote, but as long as we're expressing opinions - I would take the old logo with the new pear. ;-)

No error messages whatsoever... Recuva just goes about it's business and leads me to believe the file has been erased. Strangest thing to me is that sometimes it works and sometimes it does not, as in the example above. However, when it does not erase a file, going back and trying again and again has no effect. The file is still fully recoverable and viewable.

It is absolutely the original file - including the 'untouched' file name. Strange thing is that last time I tried it, it indeed wiped 1 of the 3 files, but not the other 2. Strange indeed. However, even the file content that it wiped, it did not touch the file name.

Is anyone actually testing this utility under Vista? Just installed the latest version. Ran in on D drive. Recovered a small text file just fine. Next I 'securely deleted' this same file. Undeleted it again and it was as legible as it was before secure deletion. My apologies in advance if I am missing the obvious here...

Have not had a chance to test secure deletion on Vista yet, but just installed it and right off the bat it is not storing my horizontal setting in the INI file. Even if I edit the INI manually, as soon as I start and close Recuva, it sets the horizontal window size back to the default...

Hate to be the bearer of bad tidings, but 2.05.555 is still not wiping my index.dat file under Vista. Tried it a couple of ways - both ticking all entries under Internet Explorer on the main screen and even adding the locaction of my index.dat file to Options/Include. The index.dat file remains untouched when I reboot, and yes, I am running CCleaner when I boot. It cleans everything but index.dat on startup. I would guess that CCleaner would be picking up the index.dat address from: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folder\Cache At least that is where the folder is specified on Vista. Cleaning that folder 'should' delete the index.dat on reboot... Shodan

Hi ! ! Trying to download the Portable version from http://www.CCleaner.com/download/builds The title says it V2.05.555, but the older version 2.04 actually downloads... Thought you would want to know.

Just want to add my 'encouraging word' to include overwriting file names in the next release. Overwriting file contents is one thing, but it's also very important to overwrite file names. One example is bank and stock statements that contain a portion of my account numbers in the file name.

Pains me to admit it, but I totally missed that too. Here is what I just now discovered. Did a scan of C drive. Selected one BMP file that was marked EXCELLENT and one that was VERY POOR. Interestingly enough, after recovery, the 'excellent' one was not viewable at all but the 'very poor' one was totally intact and viewable as a BMP file. Next, I securely deleted both of them. Neither one is viewable now. This tells me that Recuva does not ignore overwriting files based upon their state (Excellent, Poor, etc), since it overwrote the 'good' file that was marked as Very Poor...

This is annoying. Secure delete worked ok on single files this morning, but now won't delete them for love or money, either singly or in multiple selection. I'm sure glad you wrote that. I was certain it was only on my PC - possibly 'pilot error.'. When I tested secure delete yesterday, it was not working at all. Today, it seems to be either wiping content completely or, in some cases, it replaces the content with what appears to be text from a different file. Can't make rhyme nor reason exactly what it is doing on a consistent basis. One thing for sure - it is not changing file names. This would be a huge improvement if it would delete or scramble them. I will comment again as soon as I can make some sense of why secure delete seems to work sometimes but not others...

WEll.,... Today I have a different scenario. I deleted a text file to the recycle bin and emptied the bin. Ran Recuva and found the file. Erased the file with Recuva and then recovered it. Indeed the file is now empty - e.g. the text appears to have been completely overwritten with spaces(?). I am still enclosing the contents of the index tab just in case you would like it. The one problem remaining seems to be file names - they are untouched during and after the erase process. It would be wonderful if Recuva would overwrite file names the way CCleaner does. Filename: Font Web Site.txt Path: C:\$Recycle.bin\S-1-5-21-2289612737-1512734087-2000572463-1000 Size: 54 State: Excellent Creation time: 2/3/2008 08:52 Last modification time: 2/3/2008 08:52 Last access time: 2/3/2008 08:52 Comment: No overwritten clusters detected. 1 cluster(s) allocated at offset 334566

I did as you asked and posted the information per your instructions. Hope it helps.

OK here is what I did: Scanned my D drive which I had recently erased empty space on. Only file Recuva found that was recoverable was a copy of my 'config.sys' file which contained only one line of text. I recovered this file and indeed it was 'as new' and readable. Next I secuely deleted this file using Recuva. Finally, I restored the file once again to a scratch folder using Recuva. The file was 'good as new' both in file name and in content - e.g. no erasing by Recuva. Here is the debug log: [2008-02-02 08:17:56] [iNFO ] Recuva v1.10.223 [2008-02-02 08:17:56] [iNFO ] System Info: MS Windows Vista, Intel Core2 Duo CPU T7300 @ 2.00GHz, 2.0GB RAM, NVIDIA GeForce 8400M GS [2008-02-02 08:17:57] [iNFO ] No update available [2008-02-02 08:18:03] [iNFO ] Boot sector: 61KQTlRGUyAgICAAAggAAAAAAAAA+AAAPwD/AAAIAAAAAAAAgACAAP//4QQAAAAAAAAMAAAAAAD/ H04AAAAAAPYAAAABAAAAaAZ6XBl6XIQAAAAA+jPAjtC8AHz7aMAHHx5oZgDLiBYOAGaBPgMATlRG U3UVtEG7qlXNE3IMgftVqnUG98EBAHUD6dIAHoPsGGgaALRIihYOAIv0Fh/NE5+DxBieWB9y4TsG CwB126MPAMEuDwAEHloz27kAICvIZv8GEQADFg8AjsL/BhYA6EAAK8h377gAu80aZiPAdS1mgftU Q1BBdSSB+QIBch4WaAe7FmhwDhZoCQBmU2ZTZlUWFhZouAFmYQ4HzRrpagGQkGZgHgZmoREAZgMG HAAeZmgAAAAAZlAGU2gBAGgQALRCihYOABYfi/TNE2ZZW1pmWWZZHw+CFgBm/wYRAAMWDwCOwv8O FgB1vAcfZmHDoPgB6AgAoPsB6AIA6/60AYvwrDwAdAm0DrsHAM0Q6/LDDQpBIGRpc2sgcmVhZCBl cnJvciBvY2N1cnJlZAANCkJPT1RNR1IgaXMgbWlzc2luZwANCkJPT1RNR1IgaXMgY29tcHJlc3Nl ZAANClByZXNzIEN0cmwrQWx0K0RlbCB0byByZXN0YXJ0DQoAAAAAAAAAAAAAAAAAgJ2yygAAVao= [2008-02-02 08:18:03] [iNFO ] Reading MFT [2008-02-02 08:18:04] [iNFO ] Reading files [2008-02-02 08:18:06] [iNFO ] Building folders [2008-02-02 08:18:06] [iNFO ] Restoring tree [2008-02-02 08:18:06] [iNFO ] Analyzing damage [2008-02-02 08:18:06] [iNFO ] Processing recycle bin [2008-02-02 08:18:06] [iNFO ] Returning list [2008-02-02 08:18:19] [iNFO ] Deleting file config.sys Please let me know if I may provide any additional information. I will be happy to help and/or to test a fix...

Just found another possible bug in the latest Recuva - V1.10.223. Running it in Portable mode and saving the settings to an INI file, Recuva seems to be ignoring the 'window_width=' setting. I size my windows to a width of 1280 but when I close Recuva the setting does not change in the INI file. Furthermore, if I manually set window_width=1280 in my INI file, as soon as I open Recuva, it immediately changes this setting back to window_width=626, which I am assuming is the default. Running Vista Business. Everything else seems to be sticking in the INI file. Only other problem is that secure file deletion does not seem to be working on Vista either - reported elsewhere in this forum. THanks for listening ! Almost forgot to mention - The window height is saving correctly to the INI file. Only the width is not. Hope this helps.

I had not tried Recuva for some time, but since the secure deletion option was added, I decided to give it another try. The good news is that it found almost as many files (99+%) as 'Recover My Files' ($60 for registered version) and that it can store it's settings in an INI file. It's also MUCH faster than RMF. The only problem I found is that it will not securely delete files as advertised, at least under Vista. I tried to securely delete files several times and the files were always recoverable and operational. Do you have enough Vista testers ? I would be more than happy to assist in testing both Recuva and CCleaner on Vista.

HI ! ! Thanks for the reply. The above location in not where my index.dat file is stored. In fact, the folder you list does not exist at all on my Vista. (Temporary Internet Files) My index.dat file is stored in F:\Windows\Temporary Internet Files\Content.IE5 I have protected mode enabled.

Strange you should ask ! ! ;-) Index.dat suite is one of the utilities I used to identify this issue. The index.dat file in my Temporary Internet Files folder is not being touched in any way, shape or form by CCleaner upon reboot. I used index.dat suite to generate a batch file and add it's path to my registry's Run section. This indeed deletes the index.dat file in question. Then Vista recreates a new index.dat file of 32k. But it is only after running the batch file created by index.dat suite that index.dat is finally wipeded and recreated. For the record, my Temporary Internet Files are on my F drive, not C. (Just in case this is an issue with CCleaner) Here is where the folder location is stored in Vista's registry. May be different in XP. HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Cache HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

THANK YOU TRUTHSEEKER ! I was confident it was not only on my Vista machine. The file I am referring to is index.dat in the Temporary Internet Files folder. I can easily clear it on reboot by using another routine, but CCleaner should be able to do it also, especially if it is already being done under XP. Thanks again Truthseeker ! ! ! I hope this now qualifies as a legitimate bug in CCleaner.

Agreed. I did not mean to sound sarcastic, if I did. Just wish some experienced user running Vista would comment here as to whether or not it works on their PC. I am convinced, after all the testing I have done, that it is a shortcoming in CCleaner until someone proves me wrong.

Of course I am aware that a new one is created on reboot. When the old one is well over 100k in size and remains the same after reboot, yes, I am definintely aware that it was not erased. In addition, I can read the 'new' one and see all of the information that should have been deleted, but was not. Wish someone else with Vista would chime in here. As I stated before, I am able to get my index.dat file recreated, but only with the use of putting a separate routine in my Registry Run. Without that, CCleaner itself doesn't touch index.dat.

The one that is 'supposedly' marked for deletion on re-boot. This feature has never worked on my Vista Laptop. I delete it by creating a separate batch file and then putting it in my registry Run entry. Without this tweak, the index.dat that resides in my Temporary Internet Files folder remains untouched by CCleaner. CCleaner does indeed wipe the associated Temporary Internet Files folders, but not the index.dat file itself.

It sure does not on mine. Running Vista Business on a Dell Vostro and CCleaner Portable, but that should not matter. I had to initiate a separate routing to delete index.dat on reboot... Anyone else tried it on Vista ? ?