delete cache garbage dirs

[clyfe]

dmathieu implemented in this pull:

#125

the "Remove the cached file after storing it" feature.
But after removal of the file, an empty directory with the upload timestamp is left behind, filling the cache storage with empty directories.

The Carrierwave.clean_cached_files! feature helps a little, but it would be nice to have these directories removed along with the file.

[trevorturk]

I think this has been discussed before... Can you search around and see what you find?

[clyfe]

There are discussions about deleting the cached file but nothing about the companion directory that goes along.

As I said, dmathieu's patch for removing cached files that have been moved to storage deletes only the file:

@file.delete if delete_file_after_storage

but not the companion directory, say something like

if delete_file_after_storage
  @file.delete # /tmp/uploads/20110527-0535-21045-1255/--->myfile.txt<---
  also_delete_the_dir_please() # /tmp/uploads/--->20110527-0535-21045-1255<---/myfile.txt
end

[trevorturk]

Yeah, I really thought there was discussion about that, too. Maybe you can work up a pull request? You might want to wait and see if @jnicklas wants to weigh in. I think he had concerns about this, but I might just be confusing things.

[jnicklas]

Yes, this has been discussed before. My concern is that we don't actually know what the cached directory was when the cache file was created, since the user can override it to whatever they want and we risk deleting directories which we might not actually want to delete, or changing the permissions of that directory behind the user's back.

[ened]

I just ran into the case that tmp was filled up with 32768 cache directories and as such uploads did not work anymore. Hope someone comes up with a solution.. even a recommended shell script. :-(

[clyfe]

I'm thinking on something on the lines of an after_store callback to delete those dirs, that each user is to implement depending on his caching config. I'll document more as I come up with it. As I said Carrierwave.clean_cached_files! might also help, that is put that line in a rake task and call it daily via cron.

[trevorturk]

If somebody wants to work up a pull request, we can definitely discuss then. In the mean time, I'm closing this.

[ened]

I totally disagree with this procedure!

This is a open bug, people could and will run into it (like me) and it causes severe damage! Closing this issue will hide it from other people that are just starting to use this extension in the hopes of all being good and unaware of such an issue.

Please reopen and state again that you need a pull request. I will also try to work something out, even a cron job for should do.

[trevorturk]

Sorry, I just don't like leaving open issues around. We like to list "known issues" in the wiki. If you want to work something up for the wiki that would be great. Also, a pull request would be great, too ;)

I'll re-open for now, but if we don't get activity on it, I'll close again after a while.

[jnicklas]

It's one of these issues that comes up again and again, yet no one wants to submit an actually working solution. Deleting the cache directories is stupidly simple in your own application, but since we don't know anything about how your app works in CarrierWave, it's nearly impossible for us to solve. If you can come up with something, then please, submit a pull request, meanwhile, I'm with Trevor that there is no point in just letting issues lie around for years with no activity.

[ened]

@jnicklas Could you please be a little bit more specific with that? Why would I operate from within my app with a Gems generated cache files. I think we should consider having a configuration option (that defaults to true) to determine whether the cache dir should be deleted once all Carrierwave-related jobs are done or not.

I never tickle around in cache-directories that are not created by me.. and personally if anyone does.. it shouldn't be really allowed. People could copy over the original file into their own cache file and work from there.

[jnicklas]

This is the problem:

def cache_dir
  'I/can/change/this/to/whatever/I/want'
end

People can put these cached files anywhere, and if we just randomly start deleting directories, well that's no good.

[ened]

Is this cache_dir function representing a individual cache dir for a
upload or the global storage for all cache files, e.g. are the subfolders
being created there?

I think if people don't want the delete behavior, it shall be a setting.
Would bet that 99% of your users are not even aware of this cache_dir
setting. So, let's have it as configuration option and delete the dirs after
usage if the option is true.