singhals wrote: > Ian Goddard wrote: >> singhals wrote: %>< >> >> Easy. You only /copy/ them to the database. Don't delete the original. >> > > Newbies don't think of /that/. They scan thru FTM and save where-ever > it puts it. One copy, part of FTM. > >>> After the first few images were put in, most everyone discovered the >>> database was growing exponentially, >> >> If that were really the case something would be wrong. It should just >> grow linearly. > > You could be right, it's math after all, but 1 image tripled the file > size on my test. 1, 300 dpi scan of a 2x3 B&W photo. That depends on the size of the file before you added the image. How much bigger did the file grow in real terms. I'd expect it to grow by the size of the image plus whatever else went in there by way of title etc. & some indexing information. There is an other factor, however. It may well be that it starts off with a file of fixed size, mostly empty, adds data until it needs more room and then adds another fixed extent. It could even be that each time it keeps increasing the size of the extent ("They filled 4G? Right, this time we'll add 8G. That should keep them quiet for a while"). That's a good approach to space management; small databases stay within an initial small allocation but large databases get a generous allocation of space quickly and, provided there's a good sized empty block from which they can take their extents, don't end up in many scattered fragments which hurts performance. Each time the file extends it does so exponentially but this is offset by extending less frequently. In your case the acid test is what happens when you add a few more scans. Do you get to the point where you can add another scan or two without the file growing at all? %>< > > (G) But, you see, users don't think like developers. Users see "Store > images internally" and they think COOL! They don't think, "How many > images can I get on a 7G HD?" 7G? When did I last see a 7G disk? The first thing I did with this laptop was take out the 500G disk and drop in a 1Tb. Although in part this was to enable the 2nd thing which was to install Debian Linux without overwriting the original Win 7, just in case there was a problem & I had to take it back. %>< >> >> AFAICS what Gramps was originally doing was to simply note the path& >> filename of what you supplied. Only at export time did it take a copy. >> That would mean if you reorganised what you though was an >> outside-Gramps system it wouldn't have been able to find anything. >> >> BTW I installed the current version onto another Linux instance on a VM >> & tried running the import again. It still has the same default >> locations but will allow a merge. >> >> But I'd forgotten another of its little egregious features which is >> still there. Each database has a name, e.g. 1881Census. But by the >> time you've exported& reimported it's something like Family Tree 01 so >> you have to go through the lot renaming them. > > Ooops? Can't you change the code for the default to echo the file-name? That would be possible given that it's open source but there's an awful lot of Python code there so it was easier to just let it do its thing & fix it afterwards than try to understand what needed fixing where, especially as Python isn't one of my languages. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk