|Posted: Mon, 2003-12-22 15:36|
A typical picture hierarchy might resemble the following:
The Build Up to the Request
Gallery2 happily imports the images and copies the image from the source into the directory I specified that is to be the album directory. Well that's just fine and dandy everything works wonderful. Kudos to you developers for doing a fine job.
I've attempted to use a symlink'ed directory within the Gallery2 image store as the source of the images and then hoping it'd copy the symlinks into the Gallery2 album diretory (this creates an evil web of linking, but only 1 image). It didn't work so well (translated, not at all).
The Actual Request! (Finally!)
Additonal Data Part Duex
I used the normal procedures to create a new album and Gallery2 did it's thing and copied the images to the new album directory. I deleted one of the images and then tried to view the re-sized image, which of course Gallery2 complained loudly about (since the source file was deleted).
I created a symlink to the image using the same name and Gallery2 responded with a positive answer by displaying the re-sized image. This somewhat proves that the symlink concept is possible.
A concern with symlinks is that Gallery2 doesn't actually try to modify the original file. To get around this, if Gallery2 detects it's a symlink and not an image file, ensure none of the image editing techniques work. Even more "user friendly" would be to ask the user if they wanted the symlink converted to a copied file for that particular image so editing is possible and it's a copy being edited.[/]