Wednesday 18 February 2009 11:45:35 am - 8 replies
Here at work we have a site that has been running on eZ since version 3.1, and during the years I gradually updated versions until today: 4.0.3. I noticed however the storage folder seems to contain a few gigabytes of images (versioned) that are never used. I even doubt if some of these objects still exist in the database.
I wonder whether it is possible to clean up the storage folder in an automated way?
Wednesday 18 February 2009 11:41:49 pm
Good to know, I thought ez publish delete the files in storage when a object was deleted in the system...
What happen now with cluster configuration (where the images are stored in the database) when a object is deleted? If it is the same as you experienced in non-cluster installs this could be a heavy problem for big sites based on cluster...
Friday 20 February 2009 1:37:19 pm
in the current version file deletion upon object deletion is handled fine, but in the past (early 3.x versions) there have been some problems. Partly because of that, the way images are stored has been changed. I am still stuck with those leftovers.
Besides that I am also wondering what happens when you change the different image aliases in image.ini. I presume derivatives are kept when an alias is removed? Maybe there is a way to regenerate derivatives from the originals?
Modified on Sunday 22 February 2009 3:20:49 pm by Sander van den Akker
Sunday 22 February 2009 5:21:47 pm
Have you tried using ezcache.php?
Clearing Image alias cache using the --purge options should probably do the trick for old image aliases.
http://ez.no/doc/ez_publish/techn...eference/scripts/generic/ezcache_php
Sunday 22 February 2009 11:56:16 pm
I don't know about any existing script that traverse the storage folder for images / files not in use anymore, but it shouldn't be to hard to make.
Basically traversing the files and do a lookup in db to see if any versions use it.
Maybe also run flatten.php first to remove old versions, but that might not suite the site if they depend on the version history.
Tuesday 24 March 2009 11:43:09 am
Her's a workaround:
clusterize the installation so all binary files are in the database and then revert the cluster
http://ez.no/doc/ez_publish/techn...clustering/reverting_a_cluster_setup
Tuesday 02 June 2009 5:05:48 pm
You must be logged in to post messages in this topic!