I like the mountpoints.
On Jul 29, 2010 2:00 AM, "Robert Newson" wrote:
Actually, I think I prefer;
[mountpoints]
/mnt/vol0 = foo, bar
/mnt/vol1 = baz
with possible regexps or glob patterns on the right-hand side.
B.
On Thu, Jul 29, 2010 at 9:21 AM, Robert Newson
wrote:
> I'd rather go the
Actually, I think I prefer;
[mountpoints]
/mnt/vol0 = foo, bar
/mnt/vol1 = baz
with possible regexps or glob patterns on the right-hand side.
B.
On Thu, Jul 29, 2010 at 9:21 AM, Robert Newson wrote:
> I'd rather go the other way and allow some kind of globbing or regexp
> in the .ini file to f
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 mov
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: delet
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, Ra
Hmmm. Would it be crazy to walk the tree nuking the .delete files on startup
instead?
Sent from my interstellar unicorn.
On Jul 28, 2010 5:42 PM, "Damien Katz" wrote:
No, it moves the files to a fixed subdirectory (".delete"), and on start-up,
clears out that subdirectory. So if you crash after
No, it moves the files to a fixed subdirectory (".delete"), and on start-up,
clears out that subdirectory. So if you crash after the rename to the
directory, but before the delete, on the next startup it will complete the
deletion by nuking all the files in that directory.
-Damien
On Jul 28, 2
Damien,
Isn't that the current behavior, too? Now the files are just scattered
around instead of in one directory.
On Wed, Jul 28, 2010 at 16:28, Damien Katz wrote:
> The problem doing it this way is what happens if there is crash between the
> rename and the actual delete. Then you'l have a lar
The problem doing it this way is what happens if there is crash between the
rename and the actual delete. Then you'l have a large file stuck on the file
system, never actually deleted.
-Damien
On Jul 28, 2010, at 4:20 PM, Robert Newson wrote:
> All,
>
> It used to be possible to mount multipl
