Tags:
create new tag
, view all tags

Question

Hi, we would like to implement in our twiki a "cut" in the revisions available to a topic in order to keep the disk space needed for twiki on the long run finite. The idea is to implement something like: keep only the last x revisions on all (some?) topics.

The idea behind this is that expecially the (binary) attachments are rather space cnsuming if many revisions are created and kept.

I have thought that one possible solution for the attachments would have been to delete the atatchment one in a while and attach the new version from scratch. Unfortunatelly this does not work because:

  • you delete the attach (it goes on the trash) -> ok
  • you upload again the same attach (same name new version) -> ok
  • you delete the attach again -> NO you get an error that the same attach already exist in the Trash, i.e. it can not be deleted

Oviously I could once in a while clean up the Trash but I find the procedure a bit too much at human error risk.

A clean solution would be:

  1. as I have saied set twiki to keep only the last x revisions and delete the older ones by itself
  2. give the possibility to the user who is editing the Topic to delete manually only the oldest revisions before uploading a new version.

I have seen that time ago there was some idea to develop in that direction ...... is it ready? Could you give me some hints?

Thanks.

Environment

TWiki version: TWikiRelease04x01x02
TWiki plugins: DefaultPlugin, EmptyPlugin, InterwikiPlugin, TreePlugin, FlexWebListPlugin, DirectedGraphWebMapPlugin, BreadCrumbsPlugin, VotePlugin, CalendarPlugin, HolidaylistPlugin, MostPopularPlugin, ImgPlugin, HeadlinesPlugin, WeatherPlugin, AlbumOfSnapsPlugin, NewsPlugin
Server OS: Red Hat Enterprise Linux ES release 3, 2.4.21-47.ELsmp
Web server: Apache/2.0.46
Perl version: perl-5.8.0-94.EL3
Client OS: Windows XP
Web Browser: Firefox 2.0.0.6
Categories: Version control

-- CatiaLavalle - 19 Sep 2007

Answer

ALERT! If you answer a question - or have a question you asked answered by someone - please remember to edit the page and set the status to answered. The status is in a drop-down list below the edit box.

I'd recommend making a script that will be run periodically that will clean things out. I attach here the one I run daily on my site which:

  • erases debug.txt & warning.txt
  • removes topics & attachements older than N days in some webs: N=0 in Trash (cleany daily), and N=100 for a Tmp web that users can set up temporary stuff in (vote pages, ). One could clean Sandbox this way
It does not removes System topics (the ones in _default web), but clears their attachments nonetheless.

My script do not implement your solution, but it cleans the Trash.

I also from time to time do a: du -s pub/*/*/*,v|sort -n that tells me the biggest attachment archives so I can warn users and see what we can do depending of the nature of the document

  • daily_cleanup: shell (linux, bash) script to clean webs of old topic/attachments

-- ColasNahaboo - 22 Sep 2007

TWiki is designed to have a complete audit trail and to never forget. So deleting older revs of an attachment is not supported. You would need to create a custom solution. The delete attachment twice issue is a known bug.

-- PeterThoeny - 07 Oct 2007

I've just revised Colas' daily_cleanup script to not delete attachments supplied with system topics.

-- MartinCleaver - 24 Jan 2008

 
Change status to:

Topic attachments
I Attachment Action Size Date Who Comment
Unknown file formatEXT daily_cleanup manage 3.1 K 2008-01-24 - 17:08 MartinCleaver shell (linux, bash) script to clean webs of old topic/attachments
Topic revision: r4 - 2008-01-24 - MartinCleaver
 
Twitter Delicious Facebook Digg Google Bookmarks E-mail LinkedIn Reddit StumbleUpon    
  • Download TWiki
TWiki logo Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2012 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.