#1310 reopened defect

backupdb.sqlite (and all other state in ~/.tahoe?) should be scoped to the --node-url option if it is present — at Initial Version

Reported by: zooko Owned by: warner
Priority: major Milestone: undecided
Component: code-frontend-cli Version: 1.8.1
Keywords: usability Cc: zooko
Launchpad Bug:

Description

I use multiple grids (pub grid, volunteergrid, and a private family grid), and I just now had a confusing error where I ran tahoe backup and it completed quickly but produced a backup directory full of links to files with 0 shares each.

What happened, of course, was that I had previously run tahoe backup --node-url=http://127.0.0.1:3458/ to backup these files to my family grid, and now I was running tahoe backup --node-url=http://127.0.0.1:3457/ to backup these files to the volunteergrid, but I was unwittingly using the same backupdb.sqlite.

I wonder if, when the --node-url option is present, then the CLI shouldn't look into ~/.tahoe at all. Most of the configuration and state in ~/.tahoe is specific to the gateway that the --node-url points to, and the CLI will ignore it anyway and instead whatever configuration is in the tahoe-base-dir that is used by the gateway will take effect.

The only exception that I can think of right away is the private/backupdb.sqlite. Is that the only thing that affects the CLI when --node-url is present? Maybe it should be kept in a different directory.

I think I'm a bit confused about this. I'm not sure what all it means that there exists a ~/.tahoe when I'm actually using a gateway which runs as a separate user process, is specified by the --node-url option, and it has its own ~/.tahoe in its own user account. As a work-around and a way to gain clarity, I'll probably start specifying --node-directory in addition to --node-url, but this really feels wrong as it isn't a node directory at all! It is a CLI directory. :-)

Change History (0)

Note: See TracTickets for help on using tickets.