Guide To Maintaining The Avatar Images Archive, as of 1999/12/03: These procedures are rather complicated and have a lot of contingencies to deal with bad information and avoid damaging the archive, so please bear with me. There's a reason for (almost) everything you have to do. 1. Uploading/Updating The Indices Placing images in the download area is done with the 'iplace' script. iplace expects a compantion description file, named like the original ending in '.txt', with or without the extension from the original name. It will not place a file ending in '.txt' under any circumstances. If you want to place an extended description, name it 'origname.desc', and provide a description file for it as well. iplace expects the description file to have a line beginning with "Artist:" with the artist or artists who created the uploaded file. Multiple names must be separated by commas, otherwise it will treat them as one long name. Sometimes this is what you want. If there is no artist information in the description file, iplace will not place the image. If you really want to place an image for which there is no artist information, indicate the artist in the description file as "Unknown", or "Unknown-Photo" for photographs. To edit an uploaded description file to be suitable for iplace (and the index generation script 'genindex' described here later) use the 'proctxt' script. It runs an editor on the description file mentioned on the command line, and saves the original in ~ftp/pub/furry/images/uploads/Textfiles, with ".org" appended to the name, and compresses it. There are two special-purpose scripts for files uploaded by specific artists: 'procdelatxt' generates description files for Dela~* images for the "Dela the Hooda" comic strip by Style Wager and Greg Older, for all Dela~* images in the current directory. 'procchtxt' processes the description files for "Limpidity" and other images uploaded by Po Shan Cheah. Editing the uploaded description file is by far the most time-consuming part of processing uploaded files. I hope to improve this situation by accepting the upload description via a form on a web page, which can check for various errors and help the uploader create a description we can use easily. iplace then checks for an artist directory for each artist mentioned in the description file, grinding each name into a standard form suitable for a unix directory name. If an artist directory does not exist, iplace will once again not place the image. This is to catch variants of artist names that don't match the existing name in the index, and errors or typos in the description file. If the artist name is valid but new, you'll have to create the directory under ~ftp/pub/furry/images/downloads/artist by hand. If none of the above problems are enountered, iplace moves the file in the download directory and makes a hard link to the artist directory for each artist. Once you've successfully placed all the images in the download area, run 'genindex' to rebuild the index. This takes a while to run; generally you only want to run it at the end of a maintenance session to pick up all the changes at once. genindex moves the description files into the Textfiles directory, and compresses them. 2. Removing Images From The Archive To remove images from the archive, use the 'iremove' script. iremove treats each argument as the simple file name of an image, finds the index entry for it, extracts the artist names, removes the links from the artist directories and moves the file and any description files in Textfiles into a directory under 'Removals' in the upload directory. The directory is named "remove-YYYY-MM-DD" by default, but you can specify the name with the -d option. The date is always appended to the end. iremove will not remove an image which still has hard links somewhere after removing all the artist links it can. If you run into this situation, you'll have to look for the links by hand, for instance running 'find' on the inode number. I may automate this in the future. The simplest way to remove all images for an artist is to cd into the artist directory and do 'iremove -d artistname *' to place them all in ~ftp/pub/furry/images/uploads/Removals/artistname-YYYY-MM-DD. After you've successfully removed all the files you want to, run 'genindex' to regenerate the indices. It will note all the images which have been removed and strip them from the index. 3. Changing An Index Entry Currently the only way to change an index entry is to edit the index file directly. The current index file will be in ~ftp/tmp/index/index where is the number of the current version of the index. Previous versions should be compressed; the current version is uncompressed, but write-protected. Make a copy named with the next version number, and make it writable with 'chmod +w'. The index file contains one line for each file, with fields separated by TAB characters. The fields are: The obvious thing to do is to edit the entries that need changing. However it is usually easier and safer to edit the description file, delete the index entry and let genindex pick it up later. Use the saved copy from the Textfiles directory if it exists, or create one if none exists. Currently the only reason to edit an index entry directly is to preserve the date information, which may have been lost due to the modification of the image file having changed somehow or other. If you do have to do major work on the index file, run 'sort' on it after editing it, to ensure that it's in proper order for the other scripts. You can use sort's -o option to sort the file in place, like so: sort indexNNN -o indexNNN Write-protect the new index with 'chmod a-w'. You may want to compare it with the old index with diff to make sure you haven't changed anything you hadn't intended to. Compress the old index, and run genindex to regenerate the other indices. This is why it's easier to just delete the entries and let genindex recreate them; you have to run genindex anyway. This procedure is miserably awkward and mercilessly exposes the problem that we currently don't store the upload date anywhere except in the index file, and regenerating the entry may destroy this information. I plan to encapsulate all this in a script in the future.