Jump to content

mike42

Experienced Members
  • Posts

    105
  • Joined

  • Last visited

Posts posted by mike42

  1. I had the same problem. Tried a couple of times, always stuck with the soundcard pinging away.

    Then I downloaded the same installer again (again from filehippo), rebooted, installed version v1.10, uninstalled, and tried to install v1.15. And then it worked. I don't know, which of my moves solved the issue.

  2. I only have one suggestion: Defraggler should use more buffer memory. I think it's unacceptable, that it took about 8 minutes to defrag about 270 files - 87 megabytes!

    Not sure, if I understand that post correctly. You are referring to the fact, that at the end of defraging, when only small files are left, Defraggler moves every single file individually instead of just reading say 100MB of small files and move those? I fully support this request. When dealing with large files Defraggler can move 10 blocks of data in a minute and when collecting all those tiny files it takes 10 minutes for just one block.

     

    But I think Defraggler is using the Windows API routines for moving clusters. Maybe they set a limitation to accessing only one file at a time. Just a guess... :huh:

  3. Some people may not like that. Maybe build in the option to tick whether they want to be alerted when it is done. Perhaps even build defraggler with "download" packs.

    Of course, one could include an enable/disable alerts (messages) in the settings. But for sure some kind of "finished"-notification should be included.

    As for download packs, that only makes sense if a significant data volume is involved. The lang files currently take 144 KB (compressed), so I don't think it really pays off. And certainly neither for two lines of code for a message box. Maybe the languages could be selectable in the installer.

  4. Hi again!

     

    I start a new thread here following up my post from the bug section http://forum.piriform.com/index.php?showtopic=24611

    I finally figured, that I was mixing up two different things. One was a bug concerning recursively searching for files (which was partly but not quite fixed in v2.25, see http://forum.piriform.com/index.php?showtopic=24944), the other thing was searching for folders. I was fooled by the |REMOVESELF option, thinking this was in order to search for a folder recursively and then remove it. But REMOVESELF is somehow misleading. It rather searches for file(s) recursively, and when found the file(s) are deleted and if that folder is then empty the folder is removed too.

     

    However, I see no way to search for a specific foldername (preferably recursively) and remove all of them. So this would be an entirely new feature.

     

    I know a couple of applications leaving some nasty temp-folders in the middle of my data partition, and you never know exactly where. Maybe in addition to FileKey and RegKey a new FolderKey could be implemented?

     

    What are the thoughts of the Devs about this? Please let me know!

     

    Thanks,

    Mike

  5. I'm afraid I have to revert my last post in http://forum.piriform.com/index.php?showtopic=24611. I started a new thread, since it is a new bug.

     

    RECURSE now works as it should, but only for the first occurrence in each section.

     

    [Test]

    FileKey1=C:\test|name.ext|RECURSE

    FileKey2=C:\test|name.txt|RECURSE

     

    Here all files "name.ext" are found recursively, but "name.txt" does no recurse.

     

    --------------------------

    [Test]

    FileKey1=C:\test|name.ext

    FileKey2=C:\test|name.txt|RECURSE

     

    This finds "name.ext" only in "C:\test" and "name.txt" in all subfolders. It seems, only one RECURSE per section is accepted now.

    I believe this was not intended. Please, Bug fixers, can you take another look at that?

     

    Thanks,

    Mike

  6. Great! In v2.25 the first problem of my OP is resolved and works as a charm now.

     

    However I still cannot find a way to solve my 2nd problem. I repeat the description here in short:

     

    Concerning: Entries in winapp2.ini file.

    Situation: Subfolder tree like "C:\test\sub_1\dir", "C:\test\sub_2\dir", ....... "C:\test\sub_n\dir", where the "sub_x" folders are not known per se and should not be hard-coded.

    Problem: Let CCleaner find all the "dir"-folders and remove them (with |REMOVESELF).

     

    In DOS's dir command it would go like: "dir c:\test\dir /s".

    However, DOS's rd command doesn't do the job either. So probably this is no bugreport anymore but a feature request.

  7. I think, a message box like "Finished defrag" would be nice to inform the user that a defragmentation run has finished. Now it just silently re-enables the "Defrag" and "Analyze" buttons.

    Other programs give you a full-screen sized reoprt of the defrag process. That's an overkill, but some message would be nice. Or maybe just a notification sound.

     

    regards,

    Mike

  8. +1 from me for boot-time defrag.

     

    This issue has been discussed a couple of times here. Many people say: "Don't mess with these (pagefile, MFT, ...) files! They are too important." For MFT this might be true, but the pagefile can be rebuilt anytime, afaik. Anyway, other defragers have boot-time defrag too (eg. PerfectDisc), so why not Defraggler? And there are other files that might be locked during normal operation.

     

    As for the pagefile, I never had it fragmented so far. I always set it to a fixed size right after Windows install. Then there is no reason why it should ever get fragmented. So, removing the pagefile (set its size to 0), defraging free space, and rebuild the pagefile should do the job.

     

    Anyway, I think it would be an important feature. People who don't like it wouldn't have to use it.

  9. OK. Let's acknowledge that there are possibilities to use command line switches to automatically clean and shut down afterwards, and that batch files might be indispensable for many purposes. Certainly true. In this case, however, the functionallity of CCleaner includes the discribed (and not working properly) feature (http://docs.piriform.com/ccleaner/advanced...leaner-to-clean), hence no workarounds/batches should be needed. <_<

    So, just to keep in mind my OP, there are strange things going on when recursively searching for files or folders. MrT kindly agreed that someone will take a look at that issue. So let's just wait what they can find out. :rolleyes:

     

    kind regards,

    Mike

  10. It is just a minor UI bug, but still worth being fixed. It concerns the filename displayed in the status frame during defraggmentation.

     

    Whenever there is an ampersand (&) in the filename or path (which is perfectly valid in Windows), the displaying item (whatever it is: static, edit, ???) interprets the ampersand sign as marking an accelerator (as it is done eg. in menu items). Thus it omits the ampersand and underscores the following character instead.

     

    Don't know how to fix that, since I don't know what kind of display widgets are in use here. But I'm sure the devs know, what to do. ;)

     

    Mike

  11. then CCleaner will AUTOMATICALLY launch without any further clicks if the batch script ends with

     

    START CCLEANER

     

    This launches the CCleaner program but not the cleaning process. I usually run CCleaner after boot and don't want to start cleaning manually every time.

     

    Anyway, I am well aware that there are workarounds. However, my original intention was to tell the devs that there is something wrong and they might consider fixing it.

  12. you may be able to do it by manually typing up a batch file, if you know how...

    Well, I did my daily after-boot-cleaning with a DOS batch file until I came across CCleaner. I thought: hey cool, there is a nice Windows program to replace my old fashioned DOS batch. But apparently not quite <_<

     

    It would be great if the devs could look into it. I would find a functionality similar to DOS's dir-command with /s the most intuitive.

  13. I have already tried to draw attention to this topic in the general discussion board, but with very little response. Moderators, please tell me if this issue is regarded as not important or does not concern the core of ccleaners functionality. If so, I am not gonna hassle the community any further. Otherwise I am pretty sure I found a bug concerning the subfolder recursion functionality of winapp2.ini entries. It is easy to reproduce and in my opinion concerns a very basic purpose of the program, i.e. removing unwanted files from the system.

     

    1) finding files:

    - Create a folder "C:\test"

    - Create a folder "C:\test\sub"

    - Put a file "name.ext" into "C:\test" and "C:\test\sub"

    - Put the following lines into winapp2.ini

     

    [Test]FileKey1=C:\test|name.ext|RECURSE

     

    - Press "Analyze" in CCleaner

     

    Only "name.ext" in "C:\test" is found while also the one in "C:\test\sub" should be found (that is the purpose of |RECURSE, correct?).

     

    - Now replace the filekey by

    FileKey1=C:\test|name.*|RECURSE

     

    Still the same result.

     

    - Now replace the filekey by

    FileKey1=C:\test|*.ext|RECURSE

     

    Now all files are found. Why only when the filename is a wildcard? Doesn't make sense to me.

     

    2) finding folders:

    - Create a folder "C:\test\sub1\dir" and "C:\test\sub2\dir"

    - Put a file "name.ext" into each "dir" folder

     

    I don't see a way of finding all "dir" folders in all the "sub" folders (imagine, there might be 30 more "sub" folders)

    I have tried:

    FileKey1=C:\test\dir|*.*|RECURSE

    FileKey1=C:\test|dir|RECURSE

    FileKey1=C:\test\*|dir|RECURSE

    FileKey1=C:\test\*\dir|*.*|RECURSE

     

    Does anyone know a solution to this problem? Or can at least someone confirm that this is a problem?

     

    Thanx for listening!

     

    Mike

  14. winsys2.ini method is not working properly. For example, although this code works...

     

    [Thumbs.db files on Drive K]LangSecRef=3002Default=FalseFileKey1=k:\Images|*.db|RECURSEFileKey2=k:\Images|*.ms|RECURSE

     

    ...this one doesn't work at all:

     

    [Thumbs.db files on Drive K]LangSecRef=3002Default=FalseFileKey1=k:\Images|Thumbs.db|RECURSEFileKey2=k:\Images|Checklist.ms|RECURSE

     

    The second code finds absolutely nothing.

     

    EDIT: Same for winapp2.ini. This code works:

     

    [Thumbs.db files on Drive K]Section=ExperimentalDefault=TrueDetect=HKLM\SoftwareFileKey1=k:\Images|*.db|RECURSE

     

     

    But this one doesn't:

     

    [Thumbs.db files on Drive K]Section=ExperimentalDefault=TrueDetect=HKLM\SoftwareFileKey1=k:\Images|thumbs.db|RECURSE

     

    I have pointed out this problem about two or three times already some time ago.

    http://forum.piriform.com/index.php?showtopic=19175

    http://forum.piriform.com/index.php?showtopic=19877

    And a similar problem:

    http://forum.piriform.com/index.php?showtopic=20533

    I have also received the suggestion to write a DOS batch file and things like that.

    In my opinion a cleaner program should be able to do such basic things and NOT require additional DOS-batches to be run. After all, recursing for "*.ext" wildcards works, so why not make it work for "name.ext" files?

  15. Related to my previous post:

     

    Specifying specific folders recursively in winapp2.ini doesn't work. I don't see a way to remove all (sub)folders named eg. "ebay" from a directory tree.

    Say, I have a folder "%userprofile%\Eigene Dateien\Temp1\eBay" and "%userprofile%\Eigene Dateien\Temp2\eBay", an entry

    "FileKey1=%userprofile%\Eigene Dateien|ebay|REMOVESELF"

    does NOT find any ebay-folder.

     

    I have to put

    "FileKey1=%userprofile%\Eigene Dateien\Temp1|ebay|REMOVESELF"

    "FileKey2=%userprofile%\Eigene Dateien\Temp2|ebay|REMOVESELF"

     

    but there might be 27 more such folders deeper in the directory tree. It's not nice, if one has to hard-code every single folder.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.