anna24

Man, why didn't I think of closing Firefox (oh... I did). I'm reasonably certain this is a bug - at least in Vista. I'm not sure if any Piriform employees monitor forums for bug reports? Is there an "official" bug reporting site? Under "Where do I send bug reports" FAQ, it only mentions posting in forums or sending email to: http://support.piriform.com/anonymous_requests/new. In several CCL portable for Windows versions, even w/ Firefox (& Tbird) closed, they still don't find places or cookies.sqlite (among others that it should). I've tested CCL 4.16, 4.17, 5.0. If under Options> Include Items, I manually add paths to a profile & (for instance) places.sqlite, cookies.sqlite - it correctly finds them. Then in the analysis summary, they're show w/ an ! exclamation icon (not Firefox) - which is OK. But, by itself, CCL is finding other individual files in those same profiles. Some found in the "xxxxxxxx.Default User" & another user-created profile - both in the default profile path for Windows (Vista). On its own, it finds some files in custom profiles in custom locations - but not places.sqlite, cookies.sqlite (for instance). Nor does adding the latest downloaded Winapp2.ini file change whether places.sqlite, cookies.sqlite are found - as well as certain others. I put Winapp2.ini in same CCL (portable) root programs folder - where ccleaner.ini is placed by default.

Thanks dvdbane, The "t681iswd.FX-shrd-5-3-14" profile wasn't created in the Firefox (Windows) default location for profiles, then moved to F:\ - if that's what you were asking / guessing. It was created new - in the F:\ path, using Mozilla Profile Manager. Same with custom profiles (user created / named) in the default profile path. One of the biggest issues is that CCL detects the custom profiles*, and some files in them (that actually should be cleaned), but doesn't detect other (existing) commonly cleaned files in the same profiles. * It detects "custom," manually created profiles in both the default path & on F:\ partition. In both custom profiles that CCL detected & showed a couple of files to be cleaned (in both paths - "C:\users/..." and "F:\..."), I verified at least some files (that CCL didn't detect) actually contained recent browsing / history data that would normally be cleaned by any internet browser cleaner. It seems the CCL instructions of which files to look for, once it detects a custom profile, aren't complete? Is this just a bug or...? Thanks - already tried it - with & w/o the specific profile names and with or w/o the trailing backward slash ('\'). Either way, it detected some - but not many - of existing files that should be cleaned. Example "analysis" results below, even for the "Default User" profile (in default path), it detects "formhistory.sqlite" - for instance (that file contains no history data), but doesn't show files in the same default profile, like cookies or places.sqlite - or several others normally detected by cleaners. Those undetected files do exist in the profiles shown below. (Note: I replaced the user name w/ "<name>"). C:\Users\<name>\AppData\Roaming\Mozilla\Firefox\Profiles\28m01ir0.test-7-12-14\OfflineCache\index.sqlite 256 KB C:\Users\<name>\AppData\Roaming\Mozilla\Firefox\Profiles\28m01ir0.test-7-12-14\formhistory.sqlite 192 KB C:\Users\<name>\AppData\Roaming\Mozilla\Firefox\Profiles\28m01ir0.test-7-12-14\sessionstore-backups\previous.js 2 KB C:\Users\<name>\AppData\Roaming\Mozilla\Firefox\Profiles\28m01ir0.test-7-12-14\sessionstore-backups\upgrade.js-20141106120505 2 KB C:\Users\<name>\AppData\Roaming\Mozilla\Firefox\Profiles\28m01ir0.test-7-12-14\sessionstore.js 3 KB C:\Users\<name>\AppData\Roaming\Mozilla\Firefox\Profiles\6oa0cy38.Default User\formhistory.sqlite 192 KB C:\Users\<name>\AppData\Roaming\Mozilla\Firefox\Profiles\JonDoFox\formhistory.sqlite 192 KB F:\Mozilla Shared Profiles\Firefox\nj4h3qm4.FX-shrd-9-27-13\formhistory.sqlite 192 KB F:\Mozilla Shared Profiles\Firefox\t681iswd.FX-shrd-5-3-14\OfflineCache\index.sqlite 256 KB F:\Mozilla Shared Profiles\Firefox\t681iswd.FX-shrd-5-3-14\formhistory.sqlite 192 KB F:\Mozilla Shared Profiles\Firefox\t681iswd.FX-shrd-5-3-14\sessionstore-backups\previous.js 1 KB F:\Mozilla Shared Profiles\Firefox\t681iswd.FX-shrd-5-3-14\sessionstore-backups\recovery.bak 13 KB F:\Mozilla Shared Profiles\Firefox\t681iswd.FX-shrd-5-3-14\sessionstore-backups\recovery.js 13 KB F:\Mozilla Shared Profiles\Thunderbird\Profiles\lcmobcc2.TB-shrd-9-12-14\session.json 1 KB

I read several articles & posts on CCleaner & getting it to find / clean data from custom profile locations. Would / should work for any app. 1st, on their own (w/o editing the CCL ini file), several CCL versions find my Firefox profile - custom location on F:\. I see the same described behavior in CCleaner 4.16 - .17 / 5.0. They also detect Fx "user created" profiles in the default path: C:\Users\<name>\AppData\Roaming\Mozilla\Firefox\Profiles\<custom profile name>. Meaning, profiles I created & named, in the default profile path / folder (using firefox profile mgr). But, CCL only finds some Fx files - even though other files exist in these profiles that would normally be cleaned. It finds for instance, F:\Mozilla Shared Profiles\Firefox\t681iswd.FX-shrd-5-3-14\sessionstore.js and C:\Users\<name>\AppData\Roaming\Mozilla\Firefox\Profiles\xxxxxxxx.test-profile\sessionstore.js So it detects the custom profiles in both locations, except those 2 files don't exist in either profile. CCleaner detects F:\Mozilla Shared Profiles\Firefox\t681iswd.FX-shrd-5-3-14\OfflineCache\index.sqlite, but doesn't find / show the places.sqlite in the same profile, which definitely contains browsing history (& it exists). Following some topic instructions (claimed to be successful), I edited CCleaner.ini, adding: CustomLocation1=FIREFOX|F:\Mozilla Shared Profiles\Firefox CCL still doesn't find obvious files like cookies or places.sqlite - before or after editing the ini file. The profile listed above (t681iswd.FX-shrd-5-3-14) is in path: F:\Mozilla Shared Profiles\Firefox\t681iswd.FX-shrd-5-3-14\. Note: in the F:\ custom location, there isn't a "Profiles" sub-folder. Just the path / profile name, shown in previous line. Obviously, CCL "sees" the custom profiles & finds a few files, but not all files that it normally would clean. Files that do exist & do contain data. Any suggestions?

Using Defraggler 2.18 - Vista x64. My questions relate to non-OS partitions. Does the drive map depiction of white blocks (free space) fairly accurately show consolidation or fragmentation of the free space? Either after the general "Analysis" or after general defrag (but not doing free space defrag)? AFAIK, there is no reported "percent fragmentation of free space." What I'm seeing may be totally normal. On F:\ partition, I have only Firefox & Tbird profiles. Recently, I've only used one profile for each. Yesterday, after analyzing F:\, it showed ~ 57% fragmentation. Hadn't defragged F:\ in a long time. After the general defrag (no optimization to move large files;), fragmentation was 0% & the map showed nearly all files at beginning. No white blocks showed between the blue, unfragmented files blocks (and / or between files that couldn't be defragged). Following defrag, after all the consolidated (blue) files & a small section for the MFT, there was solid white blocks. ? I assume after the analysis & general defrag, the map showing all the free space white blocks together (after the files) means there would be no need to do a "free space defrag?" Less than 24 hrs later, it shows F:\ is 6% fragmented. I'm * not * concerned about the 6% value itself. ? Does even a general defrag (no free space defrag) typically leave no space for very frequently accessed files to expand? That would explain why it's already back to 6%. 6% isn't much, but only been 1 day. Just curious, more than anything. F:\ does not have System Restore / Shadow enabled. Thanks.

Sounds good. Thanks. I couldn't conceive it was by design, but I stand corrected. And thanks kroozer, for tip on clicking in white tabs to refresh. Completely unintuitive way to refresh, but still helpful. Since I don't defrag often, I'll never remember it, but still helpful. Tip on clicking a color in the map is useful - only for 1st clicked block, then all grayed out again. What would make that feature actually useful is, if it hilited the chosen color blocks, then when click the 1st of those particular colored blocks, it grayed (or somehow changed) the 1st block clicked. But left remaining blocks of the selected color blocks un-grayed. Because, the tip of clicking in white tabs to refresh doesn't work, when you've chosen one color to hilite. Just "refreshes" it to the normal view map.

Thanks, but... this is a bug report section - yes? Are you one of the devs or an official spokesperson? Even if so, "intentional designs" are often changed, because they're poor ideas. "isolate the block." If intentional, it's a bad design. Like no other app I know of. No other defrag app (I've used) grays out their map. That's like if Explorer grayed out all files in a folder (to point of nearly unreadable), because you click a file name. Or a spread sheet graying out everything when click a cell. No. Just make the clicked block bigger or bolder or put a colored frame around it or any of many ways to "isolate" the clicked block. NEVER had a problem identifying clicked blocks in any defrag (or other) apps.

Defraggler 2.15.742 x64 in Vista x64 hm prem. No other apps running in back or foreground, including any AV / FW, while using Defraggler. When NO defragging operations are active, if click any block on the map to view files in a block, it grays out the entire map, when it automatically switches to the "Highlight..." tab (a bit ironic). I see no reason to gray the map just because a block's clicked. So much that it's almost impossible to see block colors, to choose another block to click. Only way to see block colors again is click a different tab at bottom of screen, like File List, etc. The map colors then reappear, but clicking another block grays out map again. Don't remember this behavior in past versions & other defrag apps definitely don't do this. Thanks.

Some users of OTHER erasing tools than CCleaner or Recuva's own erasing function, must have then used Recuva to see what's detected. There may also be a difference (for some tools) in erasing files vs. free disk space - or not. Of course, Recuva is designed to recover deleted files, but it HAS an option to "show securely erased files." I was asking what it typically shows after erasing files w/ tools like Eraser, Shredder, etc. - not after wiping free space w/ CCleaner. In my case, it finds nothing after using other tools. Per documentation,"show securely erased files" is intended for use after wiping recovered, deleted files using Recuva's erasing tool. https://www.piriform...options-actions

Read a number of posts here & on other erasing tools' forums, but found nothing concrete about what Recuva (& perhaps tools like it) will show / recover, after running secure erasing tools. Recuva itself has a secure erasing tool, once a search for deleted files is run. But what is generally shown by Recuva for files / folders that were previously securely erased w/ various tools like Eraser, Shredder & numerous others? When Recuva is run immediately after erasing files? I don't know if running widely used "wiping" tools on a test file, on a magnetic HDD, on a NON system partition w/ no VSS, would cause Recuva to not display ANYTHING for the wiped file (under the specified circumstances). When I erase "test" files using Eraser 6.x or Shredder 2.5, then immediately run Recuva, it finds NO trace of the erased files (or at least doesn't show any). Thats' w/ ALL the Recuva options checked under "Options," except Show Non Deleted files. "Show Securely Erased Files" is checked, which seems to indicate there would BE something to show. But it shows nothing - which is good - if the result is accurate & it's not just "failing to display" what ever remenants are left of securely erased files, even if random data. The absence of displayed data doesn't mean there IS no data. Please don't start the discussion, "the only way to be positive that data is unrecoverable is to destroy the device..." I'm asking about a specific set of events here. By contrast, erasing free space on a partition using CCleaner (admittedly a different process than erasing a file), then Recuva shows a few folders w/ clearly obfuscated names & no recoverable data. That's fine. I've just not found "documentation" of what recovery tools like Recuva will / won't be able to find & display, after running (well known, respected) erasing tools at the file / folder level, under circumstances described above. Thanks.

Thanks MrT Official Bug Fixer Bug Fixers (trying to make Login123, now "title-less", feel better) I intentionally loaded some data in webappstore.sqlite in one "test" profile (located in same user acct as CCleaner was started under). It couldn't find that file. That profile was in the default location for FF. It didn't have an evercookie in it, but it had data. There're not many cleaners I know of that inspect the data inside, say an index.dat file, & decide if it needs / doesn't need cleaning. In fact, most times if files on the app's "to clean" list, exists at all - even empty - they find / delete them. I'm not biased toward BleachBit. I use CCleaner far more often, but BB, for instance, did find that webappstore.sqlite file, in this case. I really don't know what the problem was.

As I said, from any sort of "product features" (admittedly, often vague) statement, CCleaner apparently doesn't officially handle evercookies, in a reasonably complete way - as evercookies are known to exist / behave, at present. I know it doesn't (appear to) handle them completely for me. As java scripts, they can do anything that any java script might be able to do, within the browser, or from a browser to the system or to other apps. They can do what ever the hell they want, w/in the confines of js abilities. Just because the developer of evercookie & other companies that are now using the technology have been "playing fairly nice" up to now (maybe to avoid jail), in no way predicts what they may stoop to in the future. I imagine true hackers will take it & really start doing some damage.

What's the official statement of Piriform / CCleaner that states such? Maybe not listing all the locations as you did, but... As w/ any product or business, non specific statements / claims like, "We do it all;" We clean up everthing;" "We're # 1," are legally & technically meaningless. FYI, as I mentioned earlier, it doesn't find / clean webappstore.sqlite for me in Firefox, although I intentionally caused data to be saved there. Bleach Bit finds it, but it can't handle profiles in non-default locations (for now). Just sayin. I doubt any cleaning prgm could handle all locations that evercookies can be hidden (now), 100% of the time. Since evercookies are set by scripts, their developers can continually change where they're hidden. Yes, they're hacking the browsers. They were from the moment they ignored browser settings of "disable all cookies," but set them anyway, like ANY OTHER malicious script. Browsers devs may plug that hole & trackers / data miners will find another way. They SHOULD be thrown in jail / fined HEAVILY, just like someone hacking a credit card co. But for $ome rea$on, authorities & brow$er dev$ have looked the other way, so far.

Dogatmyfeet - easy now. Let's try to keep it polite. "Can't we all just get along?" I think the answer to your question is there's no official claim by CCleaner that it will handle cleaning all evercookies (why would we be interested in "some"?). That doesn't mean it doesn't - or does, AFAICT. Alan_B -what's wrong, man?!? Don't beat a newbie up. Maybe he could've phrased his question better, but your rhetoric about "will handle all future cookies..." What kind of a statement is that? How can any software claim to deal w/ any issue that hasn't been invented? The rest is just being contenscious. Help a brother out. - DAMF - CCleaner apparently does find some evercookies. Maybe all in the (for now) normal hiding places, but AFAICT there's no official claim by any official Periform representatinve that CCleaner cleans all (known, at the present) evercookies. I suppose one could intentionally go to sites known to be using them & try to get them set in all places listed on research sites, in the 12 - 15 or so places they can be stored & see what CCleaner finds. [one evercookie can be in 1, 2 or all 12 - 15 places at same time] My understanding from reading is, one cookie isn't usually stored in all possible locations. But to know if ANY cleaner can find all locations, something would have to exist in all locations. That would be a bit of work - just verifying they exist in all known locations, or creating them. Again, a bit of work

Yes, I knew that... no, really!...I...uh I bet you're a great tweaker - don't sell yourself short.

ubertweakerneverhapn, thanks.??No, I COULD read the post - I just couldn't open the image links.??Actually, the pic site opened, but images wouldn't display - which Hazelnut took care of by posting the image inline.??Thanks anyway. Also, I've discovered that one site on one of the lists of sites using persistent tracking cookie technology, contained in the link from reply # 10, is a site closely assoc. w/ a very well known browser privacy addon.??It would be very hypocritical & a pretty big slap, if true. I looked at the page source & at many of the scripts' code contained on the page, but don't have enough training to tell for sure if that site is still using the (java script) persistent tracking cookie technology.??The type of code used is spelled out pretty well on several site, but I don't know enough about it to be sure. I need to find someone w/ excellent java script coding skills to look at the page before I confront them or make it public.??There is no doubt the site is on a list of sites using the technology at one time.??Doesn't mean they still are.