I'd rather go the other way and allow some kind of globbing or regexp in the .ini file to find the databases. It was always a bit of a hack to embed the volume name into the database.
I'm thinking something like; [databases] foo* = /mnt/vol0 bar* = /mnt/vol1 baz* = /mnt/vol2 that way you can move databases between volumes without renaming them (or have replicas of databases on differently named volumes around a cluster). There would be a single, top-level .delete directory per unique volume. B. On Thu, Jul 29, 2010 at 3:21 AM, Randall Leeds <[email protected]> wrote: > This maybe gets into the realm of over-engineering, but we could track the > deleted files elsewhere so we don't have to find them. > > One solution is a _trash db. Insert, rename file, delete async and clear the > document if it succeeds. Consume changes and delete the files on startup. > Advantages: deleting only one file at a time, never losing track, no > scanning. Disadvantage: if we crash between deleting the file and deleting > the document we can't tell later if a mount is unavailable or the file is > already gone, so we risk leaving garbage files around or garbage in our > _trash and someone might hack our gibson. > > Sent from my interstellar unicorn. > > On Jul 28, 2010 6:46 PM, "Damien Katz" <[email protected]> wrote: > > I worry about installations with many many databases (like Canonical > UbuntuOne with over a million). Walking the dir structure to look for > .delete files would take a very long time. Though I suppose it could scan it > async and not block server operation. > > -Damien > > > > On Jul 28, 2010, at 5:56 PM, Randall Leeds wrote: > >> Hmmm. Would it be crazy to walk the tree nuki... >
