Two bugs with custom deleting folders

[Tex]

At the moment including custom folders to delete has two problems:

• *.* pattern is added, this should be just * to include files without an extension
  
• The parent folder should itself be deleted, having an empty directory is pointless
  

Please fix this for the next version.

[marmite]

The parent folder should itself be deleted, having an empty directory is pointless

Let's say application A creates temporary/junk files in folder X. Folder X must pre-exist because of the way that application A works.

 

User wants to clean all files in this folder and supplies the appropriate syntax to CCleaner, then runs CCleaner.

 

Application A now fails because folder X has gone.

 

That would have to be a reasonably common or at least a very plausible scenario. Unless there is alternative syntax to specify whether or not an empty folder should itself be deleted I think it's safer to leave it there. There's no overhead to an empty folder.

[ident]

Application A now fails because folder X has gone.

 

That would have to be a reasonably common or at least a very plausible scenario. Unless there is alternative syntax to specify whether or not an empty folder should itself be deleted I think it's safer to leave it there. There's no overhead to an empty folder.

 

Then application a deserves to be binned lol, That would be seriously beyond poor and i could not imagine any one releasing software with a misstake like that,

 

But i do agree with you.

 

"Leaving a empty dir is pointles"

 

If you have it in it's custom folders then obviously the file(s) is being recreated often with files that you want removing. So is it worth ccleaner removing the folder? Maybe there could be a "run once" option in include that removes teh files+folder and removes the entry from include.

 

 

as for *.* Should remove items with no file extention.

[marmite]

Then application a deserves to be binned lol, That would be seriously beyond poor and i could not imagine any one releasing software with a misstake like that,

If I write a program that creates a log (or any other) folder on install I don't expect some muppet to arbitrarily delete that folder. Neither do I necessarily expect to have to code that defensively that I'm gonna recreate the thing if it 'disappears'! It all depends on the nature of the app; but you can't apply a blanket "that's wrong".

 

User-specified folder locations may be handled differently, but not necessarily things that are part of a default application installation.

[Augeas]

• *.* pattern is added, this should be just * to include files without an extension
  

It already does. Include those files, I mean.

 

• The parent folder should itself be deleted, having an empty directory is pointless
  

Not for all of us, old bean. I use a custom folder called crap into which I throw stuff to be deleted (usually secureley deleted) by CC. I don't want the folder to go. I don't particularly want the other included folders to go either.

 

But if you do want the folder to go, then just manually edit the included folder name to remove the *.* - works a treat.

[ident]

If I write a program that creates a log (or any other) folder on install I don't expect some muppet to arbitrarily delete that folder. Neither do I necessarily expect to have to code that defensively that I'm gonna recreate the thing if it 'disappears'!

 

Its not defensively. That way of thinking is terrible when creating an app. So your telling me your app will try to writer a file to a dir that dont exist?

 

i suppose it would be better if ccleaner errored because i still had a custom folder to be cleaned in include that did not exists

 

An app that errors because a dir does not exist is beyond epic fail.

[marmite]

Its not defensively. That way of thinking is terrible when creating an app. So your telling me your app will try to writer a file to a dir that dont exist?

 

 

An app that errors because a dir does not exist is beyond epic fail.

Of course it would be defensive if it's a folder created by the application installer that you don't expect the user to be playing with!

 

By 'fail', I obviously don't mean fall flat on its face. But if an installed folder went awol I might choose one of several options. I might create the directory. But equally I might put out an error that says 'folder doesn't exist blah, blah blah'. I might just stop execution and log to the App Event Log. It all depends on the application and on the program requirement. It's not just black and white.

 

In some systems the very fact that a folder has disappeared could be indicative of a serious problem - you wouldn't want to hide that by just blindly recreating it and carrying on as though nothing has happened. And if you're running in batch or as certain services you can't just 'tell the user'.

[Nergal]

I'm leaning toward Augeas' way of thought on this, many of us use the folder section to clean self-made folders as well.

 

that said I can see us using file include for this (given we can edit the file include to be *.*) and have folder be delete folder. . . though I am not sure what you are using that you would want the folder always deleted without just dumping to program. . . .

 

Wow I'm interested to see how this works out

[ident]

But if an installed folder went awol I might choose one of several options. I might create the directory. But equally I might put out an error that says 'folder doesn't exist blah, blah blah'. I might just stop execution and log to the App Event Log. It all depends on the application and on the program requirement. It's not just black and white.

 

Well firstly you should not be writing to an installer folder. such as "program files" other then the installer.

 

On Windows Vista, it takes special permissions to write to anything in or under C:\Program Files. This is where programs live, not data. If everyone could write anything they wanted to this data, they might be able to corrupt (or worse) replace important executable files. So, Microsoft recommends storing program data in some "AppData" location.

[marmite]

Well firstly you should not be writing to an installer folder. such as "program files" other then the installer.

 

On Windows Vista, it takes special permissions to write to anything in or under C:\Program Files. This is where programs live, not data. If everyone could write anything they wanted to this data, they might be able to corrupt (or worse) replace important executable files. So, Microsoft recommends storing program data in some "AppData" location.

Thank you for your 'opinion' ident, but rest assured that I'm perfectly familiar with good practice in software deployment.

 

But regardless, your comments affect my argument how? 'An installed folder' ... in the context of my previous post ... meaning one introduced by the installer. Who mentioned the program files directory?

 

How about we stop hijacking Tex's post with this game of tennis and just agree to differ on this one.

[Alan_B]

Deleting an empty folder will NOT save any space.

 

Deleting an empty folder can WASTE GIGABYTES - not what I use CCleaner for.

 

I have especially adjusted one folder so that it and all its contents are compressed.

When 2 GByte worth of log file text is written to it, only 1 GByte of disc space is consumed.

 

The application that writes to this folder could fail if the folder is missing.

I would be annoyed that the author had not anticipated absence,

but more annoyed with CCleaner for a change that has caused inconvenience.

 

Even if the application included "defensive programming" and recreated folders destroyed by maverick cleaners,

it is unlikely that it would recreate it with my preference that contents be compressed.

 

I remember that before XP there was AutoExec.bat, which typically emptied the TEMP folder.

Does anyone know if start-up would be successful of AutoExec had an error when removing a missing folder ?

Does anyone know if absolutely EVERY piece of Microsoft code would survive a missing TEMP folder ?

 

I fully agree with the use of defensive programming that caters for the unexpected,

but totally disagree with needless wanton destruction of folders.

This imposes a special constraint that applications must NOT depend upon a folder,

and deleting the folder has not saved any space.

 

Some applications may create zero length files for future reference.

Why should they be prohibited from testing the existence of empty folders ?

 

If your favourite application failed to start properly when an empty log folder is missing,

and instead enters "defensive mode" and recreates the empty folder,

and assumes a new installation and continues to initialise and applied default configuration options,

and then prompted for custom changes to configuration before it does the job you wanted,

would you be happy with CCleaner for causing such pointless aggravation ?

 

Alan

[marmite]

I think regardless of opinions on application design, we're all pretty much agreed that deleting empty folders is not good default behaviour for CCleaner!

[Augeas]

Yep, but Tex was actually talking about folders in the Include section, and then the thread went a little astray. Why Tex would want to delete a folder every time he ran CC is his business, I guess.

[marmite]

... Tex was actually talking about folders in the Include section.

Indeed ... but you can 'include' folders created by a non-supported (or supported) app, which is where (at the risk of going astray again) I was coming from originally.

[ident]

I think regardless of opinions on application design, we're all pretty much agreed that deleting empty folders is not good default behaviour for CCleaner!

 

 

Ignoring your & my opinion. yes i 100% agree. Empty folders cost no memory. a million empty folders makes no difference to space. I never understand why people worry about empty folders.

[Nergal]

and it starts http://forum.piriform.com/index.php?showtopic=26519